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I.  INTRODUCTION 


On  March  3,  1997,  the  U.S.  Navy  promulgated  a  policy  called  Information 
Technology  for  the  21st  Century,  or  IT-21  [1],  which  stipulated  the  minimum  hardware  and 
software  requirements  for  Department  of  the  Navy  (DON)  Information  Systems  (IS).  IT-21 
was  intended  to  standardize  DON-wide  IS  development,  and  adherence  to  the  policy’s 
guidelines  have  been  implemented.  Each  component  of  the  prototype  system  of  this  thesis 
currently  meets  the  IT-21  specification  with  the  exception  that  the  host  PC’s  do  not  have 
dual  PCMCIA/PC  card  readers.  This  criterion  has  no  impact  on  the  findings  reported  in  the 
thesis. 

IT-21  mandates  that  ATM  backbones  be  utilized  within  LANs  connected  throughout 
the  Navy  (see  Appendix  A.  Section  7.  A).  It  also  mandates  the  minimum  standards 
requirements  for  software  (see  Appendix  A.  Section  7.  B).  Since  current  legacy  software  is 
designed  for  connectionless  networking,  a  dilemma  arises.  This  dilemma  and  the  current 
solution  are  the  focus  of  this  thesis. 

A.  THESIS  OBJECTIVE 

The  objective  of  this  thesis  is  to  design,  develop,  test  and  analyze  an  Emulated  Local 
Area  Network  (ELAN)  system.  The  goal  is  to  document  the  results  of  data  throughput 
across  a  simulated  ship-to-shore  ELAN.  Designing  such  a  system  serves  three  primary 
purposes: 

1.  Establishment  of  a  working  ELAN  system  within  NPS’  Advanced  Networking 
Laboratory. 

2.  Determination  of  data  throughput  for  various  network  designs. 

3.  Identification  of  an  optimal  network  configuration,  which  provides  the  best 
throughput  given  numerous  operational  scenarios. 

B.  THESIS  ORGANIZATION 

This  thesis  is  organized  as  follows.  Chapter  II  briefly  discusses  the  terms  and  basic 
building  blocks  of  an  ELAN.  Discussion  includes  advantages  of  using  an  ATM  backbone, 
reasons  for  LAN  emulation  (LANE),  LANE  components,  and  establishing  a  call  set  up 
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using  LANE.  Using  the  OSI  model,  Chapter  in  presents  two  simulation  models  used  in 
testing.  Each  model  is  created  using  OC-3  ELANs.  A  separate  legacy  100  Mbps  Fast 
Ethernet  Virtual  LAN  (VLAN),  is  also  used  to  establish  benchmark  throughput  calculations. 

Results  of  data  throughput  over  ATM  and  100  Mbps  Fast  Ethernet  networks  with 
results  plotted  under  various  conditions  are  reported  in  Chapter  IV.  The  throughput 
calculations  simulate  both  an  “inport”  and  two  “underway”  scenarios.  Throughput 
observations  of  the  underway  scenarios  are  compared.  Several  trials  are  conducted  using 
numerous  values  for  propagation  delay,  thus  simulating  various  communication  link 
possibilities.  Chapter  V  presents  conclusions  of  the  work  and  suggestions  for  future  studies. 

The  introduction  to  the  concept  of  IT-21  is  presented  in  Appendix  A.  Appendix  B 
contains  the  LAN  Emulation  Configuration  Server  configuration  file  used  in  creating  the 
network  setup.  A  detailed  ELAN  configuration  for  all  attached  LAN  Emulation  Clients  and 
Servers  is  documented  in  Appendix  C.  All  raw  data  used  to  present  the  plots  contained  in 
Appendix  E  and  F  are  included  in  Appendix  D.  Appendix  E  details  the  plots  used  to 
analyze  the  inport  scenario  testing  while  Appendix  F  displays  plots  for  critical  underway 
scenarios. 
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II.  LANE  BASICS  AND  CALL  ESTABLISHMENT 


A.  BACKGROUND 

The  majority  of  enterprise  market  share  at  the  time  of  deciding  which  protocols 
LANE  would  emulate  was  determined  to  be  Ethernet/IEEE  802.3  and  Token  Ring/IEEE 
802.5  LANs.  [2]  With  increases  in  demand  for  bandwidth  to  transfer  voice,  video  and  data 
traffic,  these  technologies  are  reaching  their  useful  limits.  Legacy  style  networks,  such  as 
Token  Ring  and  Ethernet,  are  broadcast  oriented  in  nature.  MAC  addresses  are  used  to 
differentiate  one  location  from  another.  Only  the  destination  device  with  the  correct  MAC 
address  will  process  the  incoming  information.  Processing  slows  as  the  demand  for  network 
resources,  such  as  server  access  and  transfers,  increases;  therefore,  a  new  technology  is 
needed  to  help  support  larger  broadband  networks.  ATM'  offers  an  extremely  high 
bandwidth  alternative.  Further,  LANE  can  be  implemented  at  specific  points  of  Ethernet 
congestion.  Use  of  an  edge  device,  discussed  in  detail  in  section  C,  prevents  having  to 
replace  segments  of  the  Ethernet  topology  within  a  given  LAN.  [3] 

B.  ADVANTAGES  OF  USING  AN  ATM  BACKBONE 

The  use  of  ATM  provides  a  more  efficient  data  flow  of  information  among  various 
networks.  ATM  is  well  suited  for  high  data  rate  networks  with  better  resource  utilization 
due  to  statistical  multiplexing  of  information.  ATM  also  guarantees  “Quality  of  Service 
(QoS)”  for  real-  time  and  non-real-time  services.  Salient  features  of  ATM  are  listed  in 
Table  1. 
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Operating  speeds  available:  1.54,  6.3,  25.6,  44.7, 51.8,  100,  155.5  and  622  Mbps  with  full  duplex 

capability. 


Media  access  method: 

Architecture: 

Topology: 

Cable: 

Distance: 

Devices  supported: 
Latency: 


Signaling 

Switched 

Star 

UTP  Category  3, 4  and  5;  STP;  fiber 
Copper- 100  m;  fiber-2  Km 

Adapters,  hubs,  routers,  switches,  multiplexers  and  analyzers 
Fixed 


Table  1.  ATM  Basic  Characteristics.  [4] 


C.  REASONS  FOR  LANE 

ATM  is  a  non-broadcast,  connection-oriented  technology,  which  operates  quite 
differently  from  existing,  broadcast,  connectionless  LANs,  such  as  Ethernet  and  Token 
Ring.  With  the  standards  set  forth  in  IT-21,  we  are  driven  to  use  some  type  of  interface 
between  these  two  different  technologies.  From  the  ATM  Forum:  “The  goal  of  LAN 
Emulation  is  to  present  the  illusion  that  one  or  more  ATM  ports  can  be  treated  as  one  or 
more  802.x  LAN  ports.”  [5]  LANE  is  the  driver  software  that  allows  existing  application 
software  to  connect  to  the  ATM  protocol.  Existing  LANs  differ  from  those  of  ATM  in  the 
following  areas: 

1.  The  messages  may  be  characterized  as  connectionless  versus  the  connection- 
oriented  approach  of  ATM. 

2.  Broadcast  and  multicast  are  easily  accomplished  through  the  shared  medium  of  a 
LAN. 

The  LANE  service  enables  end  systems  (i.e.,  workstations,  servers,  bridges,  etc.)  to 
connect  to  the  ATM  network  while  the  software  applications  interact  as  if  they  are  attached 
to  a  traditional  LAN.  Also,  this  service  supports  interconnection  of  ATM  networks  with 
traditional  LANs  by  means  of  bridging  methods.  This  allows  interoperability  between 
software  applications  residing  on  ATM-emulated  end  systems  and  on  traditional  LAN  end 
systems. 
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The  LANE  service  has  proven  to  be  important  to  the  acceptance  of  ATM  since  it 
provides  a  simple  and  easy  means  for  running  existing  LAN  applications  in  the  ATM 
environment.  Networking  customers  demand  coexistence  between  legacy  networks  and 
higher  bandwidth  ATM  networks.  Current  uses  of  ATM  include  workgroup  LANs  and 
LAN  backbones.  Customers  expect  to  continue  to  use  existing  LAN  applications  as  they 
migrate  to  ATM. 


1.  LANE  and  ELAN 


LANE  is  driver  software  that  imitates  LAN  services  across  ATM  using  ELANs. 
LANE  emulates  the  services  of  existing  LANs  across  an  ATM  network.  LANE  can  be 
supported  via  the  software  layer  in  end  systems.  LANE’s  purpose  is  not  to  replace  existing 
LANs  but  to  bridge  the  gap  for  ATM  simulating  a  token  ring  or  Ethernet  network  where 
higher  bandwidth  is  required.  LANE  works  at  the  data  link  layer,  level  two,  of  the  OSI 
model  as  will  be  discussed  in  detail  in  Chapter  HI.  The  network  layer  uses  LANE  to 
connect  to  the  ATM’s  adaptation  layer  as  shown  in  Figure  1. 


Network 

Layer 

Higher  Layer,  e.g., 

LLC  or  Bridging 

Relay  Function 

Layer 

Data  Management 

Link 

LAN  Emulation 

Client 

LLC  Mux 

Layer 

t 

AAL-5 

l 

null-SSCS 

Connection 

management 

SSCOP 

ATM 

Physical  Layer 

PHY 

Network 


Figure  1 .  LANE  Functioning  Within  the  OSI  Model.  [6] 


With  LANE  operating  at  layer  two,  it  is  designed  specifically  to  separate  the  ATM 
adaptation  layer  from  the  network  layer.  Thus,  all  interaction  between  the  two  is  done  via 
the  LANE  layer  “interface.”  Therefore,  the  backbone  and  edge  devices  are  all  that  need  to 
be  replaced  when  switching  to  ATM. 
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Creating  an  ELAN  allows  a  group  of  users  to  share  the  same  broadcast  regardless  of 
whether  they  are  connected  to  ATM  directly  or  through  edge  devices.  The  benefit  of  this 
upgrade  is  the  minimal  amount  of  equipment  needed  to  receive  the  advantages  of  ATM. 
Upgrading  to  ATM  does  not  require  total  replacement  of  all  network  devices  and  cabling. 
Since  each  ELAN  operates  independently  across  a  single  broadcast  domain,  communication 
between  ELANs  requires  routing  devices.  The  major  components  of  an  ELAN  network 
consist  of  ATM  end  systems  (i.e.,  ATM  workstations  and  ATM  bridges),  each  having  at 
least  one  LANE  Client  (LEC),  and  LANE  services.  We  will  examine  each  of  these 
components  in  the  following  discussion. 

2.  LANE  Components 

a  )  LAN  Emulation  Client  (LEC) 

The  ATM  Forum  defines  a  LEC  as  follows:  “The  LEC  performs  data 
forwarding  and  address  resolution,  provides  a  MAC  level  emulated  Ethemet/IEEE  802.3  or 
IEEE  802.5  service  interface  to  higher  level  software,  and  implements  the  LANE  User 
Network  Interface  (LUNI)  interface  in  order  to  communicate  with  other  components  within 
a  single  emulated  LAN.”[7]  Within  LANE,  host  computers  with  ATM  Network  interface 
Cards  (NICs)  installed  along  with  appropriate  LANE  software  drivers  are  referred  to  as 
LECs.  Edge  devices  as  stated  earlier  are  also  referred  to  as  LECs.  Use  of  edge  devices 
prevents  having  to  replace  legacy  LAN  hardware  where  it  is  not  required.  Edge  devices  use 
LANE  drivers  to  forward  information  between  an  ELAN  and  an  existing  Ethernet  or  Token 
Ring  segment.  All  LECs  regardless  of  being  an  edge  device  or  a  host,  provide  data 
forwarding.  They  also  provide  an  ATM  network  service  access  point  (NSAP)  address  and 
other  ATM  control  functions. 

b)  LAN  Emulation  Services 

LANE  services  consist  of  the  following  components:  the  LAN  Emulation 
Server  (LES),  Broadcast  and  Unknown  Server  (BUS),  and  LAN  Emulation  Configuration 
Server  (LECS).  Together,  these  three  components  are  responsible  for  ELAN  configuration, 
address  resolution,  and  broadcast  and  multicast  support. 
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(1)  The  LAN  Emulation  Server.  The  ATM  Forum’s  definition: 
“The  LAN  emulation  servers  implement  the  control  coordination  function  for  the  emulated 
LAN.  The  LESs  provide  a  facility  for  registering  and  resolving  unicast  and  multicast  MAC 
addresses  and/or  route  descriptors  to  ATM  addresses.  A  LEC  is  connected  to  only  one  LES. 
A  LEC  may  register  LAN  destinations  it  represents  and/or  multicast  MAC  addresses  it 
wishes  to  receive  with  its  LES.  A  LEC  will  also  query  its  LES  when  the  LEC  wishes  to 
resolve  a  MAC  address  and/or  route  descriptor  to  an  ATM  address.  The  LES  will  either 
respond  directly  to  the  LEC  or  forward  the  query  to  other  clients  so  they  may  respond.”  [7] 
ATM  to  ATM  address  resolution  is  conducted  using  a  network  service  access  point  (NSAP) 
address.  The  LES  provides  the  MAC  to  NSAP  address  resolution  for  each  member  of  the 
local  ELAN.  LES  software  can  be  installed  on  any  device  in  the  ATM  network  but  is 
normally  located  within  a  switch.  Each  LEC  registers  its  MAC  and  NSAP  addresses  with 
the  LES,  allowing  the  LES  to  perform  MAC-to-NSAP  address  resolution.  The  LES  accepts 
MAC  address  queries,  translates  the  MAC  addresses  into  an  NSAP  address,  and  responds 
back  to  the  LEC  directly.  The  LES  enables  a  source  LEC  to  establish  a  communication  path 
to  a  destination  LEC  upon  completion  of  any  address  resolution  issues.  [7] 

(2)  Broadcast  and  Unknown  Server.  The  broadcast  unknown  server 
supports  the  broadcast  messaging  within  an  ATM  network.  As  defined  by  the  ATM  Forum, 
the  BUS  “handles  data  sent  by  LEC  to  the  broadcast  MAC  address  (’FFFFFFFFFFFF), 
multicast  data,  and  initial  unicast  data  which  are  sent  by  a  LEC  before  the  data  direct  target 
ATM  address  has  been  resolved  (before  a  data  direct  VCC  has  been  established).”  [7] 

A  LEC  sees  a  single  BUS.  The  multicast  server  function  provided  in 
the  BUS  is  required  as  part  of  LANE  to  provide  the  connectionless  data  delivery 
characteristics  of  a  shared  network  to  LECs.  The  main  tasks  of  the  BUS  are  to  distribute 
data  with  multicast  MAC  addresses  and  to  deliver  initial  unicast  data,  where  the  MAC 
address  has  not  yet  been  resolved  to  a  direct  ATM  connection.  All  broadcast,  multicast  and 
unknown  traffic  to  and  from  a  LEC  passes  through  this  single  entity. 

A  LEC  sends  data  frames  to  the  BUS,  which  serializes  the  frames 
and  re-transmits  them  directly  or  indirectly  to  other  LECs. 
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The  BUS  implementation  may  have  multiple  interfaces,  which 
support  receiving  and  forwarding  of  specific  multicast  MAC  addressed  frames  over  multiple 
VCCs.  If  a  LEC  does  not  need  to  receive  all  multicast  MAC  addressed  frames,  it  may 
inform  the  LES  during  initialization.  The  LES  may  then  selectively  forward  multicast  MAC 
addressed  frames  to  only  those  LECs  that  requested  them. 

It  is  standard  practice  to  co-locate  the  LES  and  BUS,  creating  what  is 
known  as  an  “intelligent  BUS.”  The  advantage  of  the  intelligent  BUS  is  that  the  BUS  takes 
advantage  of  the  LES  address  table  and  routes  traffic  only  to  the  destination  LEC.  This 
implementation  reduces  undesired  broadcast  traffic  and  increases  efficiency.  [7] 

(3)  LAN  Emulation  Configuration  Server  (LECS).  A  LECS 
supports  the  configuration  of  large  broadband  networks  by  assigning  each  LEC  to  one  or 
more  specific  ELANs.  As  defined  by  the  ATM  Forum,  a  LECS  “assigns  individual  LECs  to 
different  emulated  LANs.  Based  upon  its  own  policies,  configuration  database  and 
information  provided  by  LEC  and  other  devices,  a  LECS  assigns  any  client  which  requests 
configuration  information  to  a  particular  emulated  LAN  service  by  giving  that  client  the 
appropriate  LES  ATM  address.  This  method  supports  the  ability  to  assign  a  client  to  an 
emulated  LAN  based  on  either  the  physical  location  (ATM  address)  or  the  identity  of  a 
LAN  destination,  which  it  is  representing.  All  LECs  must  be  able  to  obtain  information 
from  a  LECS  using  the  configuration  protocol.”  [7]  The  LECS  is  normally  located  in  an 
ATM  switch  along  with  LES  and  BUS. 

The  LECS  make  configuration  assignments  based  on  administrative 
policies,  database  information,  and  physical  location  based  on  information  provided  by  a 
LEC.  After  determining  eligibility,  the  LECS  provides  the  LEC  with  the  ATM  address  of 
their  appropriate  LES.  The  LECS  maintains  a  database  that  contains  administrative 
information  for  each  associated  ELAN  including  ELAN  type,  application  type  supported, 
and  LES  address  by  which  each  requested  LEC  must  register. 

The  LECs  register  with  the  LECS  in  one  of  the  following  three 
methods.  The  first  method  is  through  a  predefined  LECS  address  at  the  LEC.  The  second 
method  is  through  an  interim  local  management  interface  (ILMI)  discovery.  ILMI  is  a 
standard  that  specifies  the  use  of  SNMP  in  an  ATM  management  information  base 
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providing  network  status  and  configuration  information.  The  third  and  final  method  is 
through  a  “well-known”  address  of  the  LECS.  A  “well-known”  address  is  the  ATM  NSAP 
address  specified  by  the  ATM  forum.  As  discussed  earlier,  the  NSAP  address  enables  LECs 
to  communicate  with  the  LECS  and  LES. 

In  order  to  realize  emulated  connectionless  LAN  communication  in  a 
connection  oriented  ATM  environment,  LANE  servers  work  together  to  provide  address 
resolution  and  data  forwarding  for  each  attached  client. 

3.  Establishing  a  Call  Up  Using  LANE 

LANE  supports  both  switched  virtual  circuits  (SVCs)  and  permanent  virtual  circuits 
(PVCs).  This  is  completed  using  ATM  Virtual  Channel  Connections  (VCCs).  A  VCC  is  a 
logical  connection  and  is  the  basic  unit  of  switching  within  ATM.  VCCs  are  the  lowest 
level  of  logical  paths  within  ATM  networks.  Figure  2  illustrates  the  relationship  of  VCCs 
within  ATM’s  connection-oriented  environment. 


Figure  2.  ATM  Connection  Relationships.  [8] 


Within  LANE,  we  are  concerned  primarily  with  two  categories  of  VCCs:  control 
messaging  and  data  traffic.  Figure  3  illustrates  the  VCC  within  a  simple  ELAN,  which 
connects  two  LECs. 
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Figure  3.  VCC’s  Connections  Within  an  ELAN.  [6] 


a)  Control  Messaging 

This  type  of  connection  is  used  for  control  traffic  functions:  initialization, 
registration  and  address  resolution.  These  are  briefly  described  as  follows. 

1 .  Initialization  involves  obtaining  the  NSAP  address  of  the  LES,  joining  or  leaving 
an  ELAN  and  declaring  if  a  LEC  desires  to  receive  LE_ARP  requests  for  any 
traffic  with  unregistered  destinations. 

2.  Registration  requires  furnishing  of  all  applicable  MAC  addresses  a  LEC  is  setup 
to  respond  to. 

3.  Address  resolution  requests  and  replies  are  used  to  obtain  the  ATM  address 
associated  with  LECs  with  particular  MAC  addresses. 

There  are  three  distinct  control  message  VCCs  used  in  establishing 
communications  of  a  LEC  within  an  ELAN.  The  first  connection  is  the  LEC  to  LECS 
configuration  direct  VCC.  The  configuration  direct  VCC  is  a  bi-directional  VCC  setup  by 
the  LEC  as  part  of  the  LECS  connection  phase  and  is  used  to  obtain  configuration 
information,  including  the  address  of  the  LES  [6].  The  entity  may  maintain  this  VCC  while 
participating  in  the  emulated  LAN  for  further  queries  to  its  LECS.  The  configuration  direct 
VCC  may  be  used  to  inquire  about  a  LEC  other  than  the  one  to  which  the  configuration 
direct  VCC  is  attached.  Figure  4  illustrates  the  connection  of  the  LEC  to  LECS  via  the 
configuration  direct  VCC. 
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Figure  4.  Configuration  Direct  VCC  Between  DEC  and  LECS.  [6] 

The  second  connection  established  is  the  control  direct  VCC.  The  purpose 
of  this  VCC  is  to  maintain  communications  between  the  LEC  and  DES  throughout  the 
period  during  which  the  LEC  is  a  member  of  the  ELAN.  This  VCC  is  established  during 
the  initialization  stage  when  the  LEC  joins  the  ELAN.  The  control  direct  VCC  is  a  bi¬ 
directional  point-to-point  flow  to  the  LES  for  sending  control  traffic.  The  LEC  is  required 
to  accept  control  traffic  from  this  flow. 

The  final  control  messaging  VCC  is  the  control  distribute  VCC.  The  ATM 
Fomm  defines  the  control  distribute  VCC  as  an  optional  unidirectional  point-to-multipoint 
VCC  [6].  This  VCC  is  used  to  distribute  control  traffic  to  the  LEC.  The  control  distribute 
VCC  is  normally  setup  during  the  initialization  phase  by  the  LES.  If  a  setup  is  directed  by 
the  DES,  the  LEC  is  required  to  accept  the  control  distribute  VCC  prior  to  acceptance  into 
the  ELAN.  Once  established,  the  call  must  be  maintained  throughout  the  entire  ELAN 
connection  of  the  attached  LEC.  Figure  5  illustrates  the  VCCs  functioning  between  the 
LEC  and  LES. 
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Figure  5.  LEC  to  LES  Control  Messaging  VCCs.  [6] 

b)  Data  Traffic  Messaging 

The  second  group  of  VCCs  is  the  data  traffic  (channel)  VCCs.  There  are 
three  types  of  data  connection:  multicast  send,  multicast  forward,  and  data  direct  [6]. 

The  purpose  of  the  multicast  send  VCC,  once  established  between  the  source 
LEC  and  the  BUS,  is  to  allow  the  LEC  to  transfer  multicast  traffic  to  the  BUS.  In  return,  the 
BUS  uses  the  channel  to  send  data  to  the  LEC.  Upon  initial  call  establishment  between  two 
LECs  the  multicast  send  VCC  is  used  to  transfer  unicast  data  while  the  source  LEC  awaits 
the  LE_ARP  reply  from  the  LES.  The  multicast  send  VCC  is  a  bi-directional,  point-point 
VCC  that  is  maintained  throughout  the  ELAN  connection. 

The  multicast  forward  VCC  is  established  immediately  following  the 
multicast  send  VCC.  The  multicast  forward  VCC  is  used  by  the  BUS  to  transfer  data  to  the 
attached  LECs.  The  multicast  forward  VCC  is  either  point-to-multipoint  or  unidirectional 
point-to-point.  This  VCC  is  established  at  ELAN  setup  and  is  functional  prior  to  allowing 
the  LEC  to  transfer  data  within  the  ELAN.  The  use  of  the  multicast  forward  and  multicast 
send  VCCs  makes  ATM  more  efficient  in  that  data  does  not  have  to  wait  for  a  complete 
connection  to  be  obtained  before  data  is  actually  transferred  within  the  ELAN.  The  bus 
forwards  the  unknown  traffic  to  all  registered  LECs  within  the  ELAN  using  multicast 
forward  VCC’s.  Like  the  multicast  send  VCC,  this  connection  is  active  throughout  the 
period  in  which  a  LEC  is  connected  to  the  ELAN.  Figure  6  illustrates  the  connection  of 
both  the  multicast  send  and  multicast  forward  VCCs  between  the  LEC  and  BUS. 
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Figure  6.  LANE  LEC/  BUS  Multicast  VCC.  [6] 


The  final  data  traffic  VCC  is  the  data  direct  VCC.  The  data  direct  VCC  is 
used  to  transfer  unicast  traffic  between  a  source  and  destination  pair  of  LECs.  This  VCC  is 
established  upon  receipt  of  the  LE_ARP  reply  message  from  the  LES,  which  holds  the 
NSAP  address  of  the  destination  LEC.  Once  established,  all  traffic  between  the  source  and 
destination  LECs  is  done  over  the  data  direct  VCC.  Data  direct  VCCs  are  functional  for  the 
duration  of  time  required  to  send  data  traffic.  Figure  7  is  an  illustration  of  the  data  direct 
VCC  between  two  LECs. 


Figure  7.  LANE  LEC  to  LEC  Data  Direct  VCC.  [6] 


13 


Quality  of  Service  is  monitored  and  enforced  from  the  time  of  establishment 
to  the  time  of  breakdown  of  the  data  direct  VCC.  The  multicast  traffic  within  the  multicast 
send  and  multicast  forward  VCCs  is  not  monitored  with  regards  to  QoS;  therefore,  there  is 
no  guarantee  of  service  at  this  point  in  the  call  establishment. 

Understanding  the  call  setup  and  breakdown  is  important.  Recall  that  the 
connection  between  any  two  LECs  is  maintained  throughout  the  duration  of  the  call  via  the 
data  direct  VCC.  As  more  LECs  are  allowed  to  enter  an  ELAN,  more  data  direct  VCC’s  are 
required  to  transfer  data  between  stations.  Within  an  ATM  network,  QoS  contracts  are 
negotiated  prior  to  allowing  a  LEC  to  participate  within  the  ELAN.  Therefore,  with  limited 
bandwidth,  the  number  of  participating  LECs  is  potentially  limited,  thus  placing  a  maximum 
on  the  number  of  participants  within  an  ELAN. 

With  this  in  mind,  this  study  focused  on  the  throughput  capability  of  two 
types  of  ATM  WANs.  Chapter  HI  demonstrates  the  model  layout  used  to  conduct  testing 
and  analysis. 
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IH.  ESTABLISHING  A  SHIP-TO-SHORE  SIMULATION  MODEL 


A.  BASIC  BATTLEGROUP  WAN  STRUCTURE 

Figure  8  represents  a  simple  battlegroup  representation  in  which  multiple  ships  and 
shore  stations  may  participate  within  a  WAN.  Various  segments  of  this  scenario  will  be 
studied  in  regards  to  throughput  capacities.  However,  a  detailed  understanding  of  the 
hardware  and  software  requirements  incorporated  in  the  creation  of  an  ATM  WAN  should 
be  understood  to  assist  in  network  establishment. 


Figure  8.  Sample  Batdegroup  WAN  Scenario. 
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Figure  9  focuses  only  on  the  ship-to-shore  inport  portion  described  in  Figure  8.  This 
cloud  diagram  represents  any  number  of  workstations  and  servers  attached  to  a  scalable 
WAN  environment.  Figure  9  is  used  in  Chapter  IV  to  benchmark  the  OC-3  ATM  network 
to  a  standard  100  Mbps  Fast  Ethernet  network.  The  benchmark  comparison  to  Fast  Ethernet 
is  calculated  only  in  the  zero  propagation  delay  trial  as  Ethernet  was  not  intended  for  use 
over  a  wide  area. 


Figure  9.  Ship(inport)-to-Shore  ATM  with  Shore-to-Shore  Fast  Ethernet  Connection. 


B.  EQUIPMENT  SETUP 

Equipment  setup  will  be  discussed  in  the  context  of  the  physical,  data  link,  and 
network  layers  of  the  OSI  model  displayed  in  Figure  10. 


Figure  10.  LANE  Included  OSI  Model.  [3] 
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1.  Physical  Layer 

The  physical  layer  incorporates  all  hardware  required  for  use  in  the  simulation 
model.  Each  of  the  two  domains  used  similar  hardware.  The  ship  domain  consists  of  two 
workstation  PCs.  One  PC  is  established  as  the  ship’s  server/router,  and  the  other  is  one  of 
what  could  be  many  shipboard  workstations.  The  server/router  is  a  Dell  Dimension  XPS 
D266  operating  with  196  MB  RAM.  A  FORE  systems  PCA-200E  2.0.1  (PCI  bus)  network 
interface  card  (NIC)  is  installed  for  network  operation.  The  workstation  is  a  Dell  Dimension 
XPS  H266  operating  with  98  MB  of  RAM  with  PCA-200E  2.0.1  ATM  NIC  installed.  Both 
of  die  PCs  are  connected  to  a  FORE  systems  ASX-200BX  ATM  switch  by  SC-SC 
multimode  62.5/125  pm  fiber  cables.  The  ASX-200BX  utilizes  one  Intel  I960HA  processor 
operating  over  hardware  version  F  with  16  MB  DRAM  and  4MB  of  flash  memory. 

The  shore  domain’s  server/router  is  a  Dell  Dimension  XPS  Pro200n  with  128  MB 
RAM.  As  within  the  ship  domain,  the  shore  server/router  utilizes  a  FORE  systems  PCA- 
200E  ATM  NIC.  Also  installed  is  a  3Com  905B-TX  Fast  Ethernet  NIC  used  for  accessing 
the  Internet  and  other  shore  servers.  The  shore  workstation  is  a  Dell  Dimension  XPS 
Pro200n  operating  with  64  MB  RAM,  and,  similar  to  the  ship  domain,  a  FORE  PCA-200 
ATM  NIC  is  installed.  The  shore  domain  PCs  are  connected  to  a  FORE  systems  ASX- 
200BX  through  the  same  fiberoptic  cabling  as  used  in  the  ship  domain. 

The  two  domains  are  physically  interconnected  via  the  same  multimode  fiber  as 
discussed  above.  An  Adtech  SX-14  data  channel  simulator  is  inserted  between  the  most 
remote  member  of  the  shore  ELAN  and  its  associated  server.  The  SX-14  is  installed  with 
single  mode  fiber  transmit  and  receiver  interface.  This  presented  a  unique  problem  that  was 
overcome  through  the  use  of  an  airgap  on  the  transmit  side  of  the  SX-14.  The  airgap  allows 
for  enough  attenuation  loss  between  the  transmitter  laser  and  the  multimode  fiber  to  prevent 
overdriving  and  potentially  damaging  the  receiver’s  photo  diode.  It  is  understood  that  an 
airgap  is  a  temporary  fix;  however,  it  was  decided  that  the  cost  of  upgrading  the  two  ASX- 
200  BX  switches  to  conclude  a  long  haul  or  medium  haul  single  mode  module  was  not  cost 
effective  at  $18000  per  module. 
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Figure  11  is  the  physical  layer  simulation  model  used  to  demonstrate  the  single 
ELAN  system.  Figure  12  is  a  layout  diagram  of  the  physical  layer  of  the  simulation  model 
of  a  two-ELAN  system. 


Ship  Based  LEC 


Diagram:  By  LT  Joseph  Prisetia,  USH 
17  July,  IMS 


Figure  11.  Single  ELAN  Physical  Layer  Simulation  Model. 
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Figure  12.  Two  ELAN  Physical  Layer  Simulation  Model. 

2.  Data  Link  Layer 

A  closer  look  at  Figure  10  reveals  that  it  is  in  the  data  link  layer  of  the  OSI  model 
where  the  LAN  emulation  layer  resides.  Several  key  installation  areas  are  attended  to  in  this 
layer  to  create  the  working  ELAN  environment  as  in  Figure  1 1  and  Figure  12. 
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a )  IAN  Emulation  Server  Setup 

The  first  step  in  creating  an  ELAN  is  configuring  the  LECS.  Appendix  B 
contains  the  LECS  configuration  file  used  within  the  simulation  model.  A  line  by  line 
breakdown  of  Appendix  B  is  provided  to  better  understand  the  functionality  of  the 
LECS.CFG  file.  The  names  of  all  ELANS  that  have  accept  keys  must  be  included  in  the 
statement: 

Match  Ordering:  Shore,  Ship 

This  line  of  code  provides  the  order  in  which  to  apply  the  accept  and  reject  rules  to  the 
group.key  statement.  The  groups  in  the  simulation  are  “shore”  and  “ship,”  and  the  keys  are 
“accept”  as  denoted  by: 

shore  accept:  xx.xxxx.xx.xxxxxx.xxxx.xxxx.xxxx.xxxxxxxxxxxx.xx 

ship  accept:  xx.xxxx.xx.xxxxxx.xxxx.xxxx.xxxx.xxxxxxxxxxxx.xx 

where  the  use  of  the  “don’t  care”  address 

xx.xxxx.xx.xxxxxx.xxxx.xxxx.xxxx.xxxxxxxxxxxx.xx 

allows  for  any  client  to  be  accepted  within  an  ELAN.  The  length  in  bytes  of  the  largest 
frame  is  specified  by: 

Maximum_frame_size:  1516 

Frame  selection  size  options  are  1516,  4544,  9234,  and  18190.  The  default  for  Ethernet  is 
1516  and  is  therefore  used  throughout  the  simulation  model. [9]  The  maximum  frame  size 
calculation  for  Ethernet  is  based  on  the  maximum  of  1518  octets  for  the  DA  (6  octets),  SA 
(6  octets),  Type/Length  (2  octets),  Info  (1500  octets),  and  FCS  (4  octets)  fields.  Since 
LANE  data  frames  also  includes  the  2  octet  LANE  Header  (LEH)  (but  does  not  include  the 
FCS  field),  the  emulated  Ethernet  maximum  frame  size  is  1516  octets  (LEH,  DA,  SA, 
Type/Length,  and  Info  fields).  This  results  in  32  ATM  cells  (48  byte  payload  per  cell)  or 
1536  octets  including  12  octets  of  padding  and  the  8  octet  trailer  for  AAL5.  [6] 

The  shore  ASX-200  BX  ATM  switch  uses  NS AP  address: 

Shore.Address: 

47.0005. 80.FFE 1 00.0000.F2 1  A.44A2.002048 1 A44A2.0 1 


19 


The  same  address  is  also  used  in  the  following  line  of  code: 

Shore.BUS_Address: 

47.0005.80.FFE 1 00.0000.F2 1  A.44A2.002048 1 A44  A2.0 1 

which  follows  the  convention  that  shore  LES  and  BUS  are  co-located  to  create  the 
“intelligent  BUS”  as  discussed  in  the  BUS  segment  of  Chapter  II.  The  final  line  of  code 
corresponding  to  the  shore  ELAN  is  the 

Shore.LAN_Name:  shore 

which  refers  to  the  alias  “shore”  and  is  used  to  associate  with  the  switch  NSAP  address.  The 
ship  ELAN  code  is  nearly  identical  to  the  shore  ELAN  code  with  the  exception  of  the 

Ship.Address:  and  ship.BUS_Address 

fields,  which  contain  the  NSAP  address  of  the  ship’s  ASX-200  BX  ATM  switch: 

Ship  address: 

47.0005. 80.FFE100.0000.F21A.3E9A.0020181A3E9A.02 
Ship.BUS.Adress: 

47.0005 .80.FFE 1 00.0000.F2 1  A.3E9  A.0020 1 8 1  A3E9A.02 
The  .LAN_name  is  modified  to 

Ship.LAN_name:  ship 

It  should  be  noted  at  this  point  that  the  last  byte  (2  characters)  is  reserved  as  the  selector 
byte.  The  shore  selector  byte  has  been  arbitrarily  set  to  01,  and  the  ship  selector  byte  has 
likewise  been  set  to  02.  With  this  LECS  configuration  file,  all  LECs  wishing  to  join  either 
ELAN  must  attempt  to  establish  a  VCC  to  the  “well-known”  LECS  address  specified  as 
47.0079.00.000000.0000.0000.0000.00A03E000001 .00  as  required  by  the  ATM  forum.  A 
special  note  is  that  00A03E  forms  the  ATM  Forum  assigned  Organizational  Unit  Identifiers 
(OUI)  octet  with  000001  having  been  allocated  by  the  ATM  Forum.  [7] 

The  procedure  for  uploading  the  LECS  .CFG  file  were  followed  in 
accordance  with  the  guidelines  for  configuring  an  emulated  LAN,  outlined  in  section  3.6.3 
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of  reference  [9],  for  both  ASX-200  BX  switches.  In  Step  2  of  the  installation,  the  command 
“configuration  Lane  LECS  new  OXOC-2B  LECS.CFG”  was  used  by  default,  providing  the 
switches  with  the  ATM  Forum’s  “well-known”  LECS  address.  Once  these  steps  have  been 
completed,  the  LANE  services  are  functional  and  awaiting  the  LEC  installations  to  complete 
the  data  link  layer  requirement. 

b)  LAN  Emulation  Client  Setup 

The  understanding  of  the  installation  of  LANE  drivers  is  critical  in 
establishing  a  LANE  environment.  There  are  two  parts  to  the  installation  of  FORE  ATM 
adapter  software.  The  first  step  is  the  installation  of  the  ForeRunner  ATM  adapter  software. 
This  software,  once  loaded,  provides  several  setup  options  to  the  administrator.  All  settings 
for  the  simulation  model  were  set  to  default.  It  is  important  to  note  that  the  fragment  size  is 
set  to  appropriately  1536  for  Ethernet  emulation.  Figure  13  is  the  ForeRunner  PCA  ATM 
adapter  dialog  box.  Since  OC-3  is  the  means  used  to  connect  the  NIC  to  the  switch,  the 
“OC3  framing:  SONET”  and  the  “empty  cell  insertion:  unassigned”  options  are  selected.  If 
multiple  NICs  are  installed  the  adapter’s  identifier  will  reflect  the  ATM  adapter  number. 


ForeRunner  PCA  ATM  Adapter 

T ransmit  B  utter  Count:  | 

Transmit  Queue  size:  ^2 

Defaults 

Receive  Butter  Count:  ~  j|.| 

Receive  Queue  Size:  ^4 

Fragment  Size:  *  536 

Adapter's  Identifier:  2 

rOC3  Framing - j 

1  1  SONET  CSDH  |  138133 

! - ' 

r* Empty  Cell  Insertion - 

|  &  Unassigned _ Oldie _ 

Copyright  (c)  1996,1937  FORE  Systems,  Inc.  All  rights  reserved. 


Figure  13.  ForeRunner  PCA  ATM  Adapter. 


The  second  step  is  the  loading  and  configuring  of  the  ELAN  adapter  drivers.  The 
ELAN  LECs  are  defined  in  this  step.  Page  5-10  of  reference  [10]  describes  in  detail  the 
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steps  taken  to  complete  the  installation.  Figure  14  is  the  dialog  box  display  for  the 
ForeRunner  emulated  LAN  adapter.  The  selections  of  the  values  described  in  Figure  14  are 
identical  for  both  the  ship  and  shore  workstations. 


The  configuration  of  the  shore  server  LEC  requires  ATM  to  be  installed  as 
adapter  2.  Adapter  number  1  is  a  standard  3Com  905B-TX  100  Mbps  Fast  Ethernet  adapter 
used  to  connect  the  other  VLAN  equipment  and  the  Internet. 


The  ship  server/router  is  unique  in  its  configuration.  The  capability  of  the 
PCA  200-E  ATM  adapter  allows  a  single  adapter  card  to  function  over  two  separate 
ELANs.  With  this  capability,  only  one  LEC  onboard  ship  needs  to  participate  in  both  the 
ship  and  shore  ELANs  to  provide  the  shore  services  to  the  ship  workstations.  The  only 
additional  step  required  in  establishing  the  simulation  setup  is  the  configuring  of  the  ELAN 
adapter  drivers. 


ForeRunner  Emulated  LAN  Adapter 


C  Disable  Virtual  Driver 
<?  [Enable  Virtual  Driver: 


LAN  Type - 

f?  Ethernet 
C  Token  Ring 


Adapter  Identifier 


2 


C  Automatic  ELAN  Selection 
Manual  ELAN  Selection 
Emulated  LAN  Name: 


shore 


OK 


-Frame  Size 


<•1516 
C  4544 

C  9234 
r 18190 


Caned 


Defaults 


Advanced... 


Help 


Copyright  (c)  1996.1997  FORE  Systems.  Inc.  All  rights  reserved. 


Figure  14.  ForeRunner  Emulated  LAN  Adapter. 


The  ship  ELAN  server/router  needs  to  have  the  drivers  installed  twice  with 
the  manual  ELAN  selection  block  as  displayed  in  Figure  14  set  to  “ship”  for  one  of  the 
ELAN  adapters  and  set  to  “shore”  for  the  other.  Figure  15  is  the  network  neighborhood 
adapter  window  detailing  the  adapters  installed.  Note  only  one  ELAN  name  is  allowed  per 
each  ELAN  adapter.  By  issuing  the  ASX-200BX  command: 
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configure  LANE  LEC>  new 

the  switch  can  be  added  as  a  participating  LEC  within  the  respective  ELAN.  Appendix  C 
describes  in  detail  the  following  important  parameters  created  during  the  installation  and 
configuration  of  the  ship  and  shore  ELANs: 

1.  ELAN  Name. 

2.  LES  and  BUS  NSAP  addresses. 

3.  The  LANE  type  and  maximum  packet  size. 

4.  The  assigned  non-proxy  control  distribute  VCC,  proxy  control  distribute  VCC 
and  the  multicast  forward  VCC. 

5.  The  number  of  LECs  assigned  to  the  ELAN. 

6.  Each  EEC’s  NSAP  and  MAC  address  and  the  currently  assigned  control  direct 
VCC. 

7.  The  switches  assigned  name  and  NSAP  address,  which  includes  the  operator 
assigned  selector  byte  used  previously  when  configuring  the  switch  as  a  member 
of  an  ELAN. 


t 

Figure  15.  Network  Dialog  Box  for  Ship’s  Server/Router. 
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3.  The  Network  Layer 

The  network  layer  is  the  third  level  in  the  OSI  model.  Here  we  can  choose  TCP/IP, 
NETBEUI  or  IPX/SPX  to  bind  our  ELAN  [10].  For  the  simulation  model,  TCP/IP  has  been 
chosen  to  handle  the  movement  of  packets  throughout  the  network.  Figure  16  is  a  diagram 
detailing  the  IP  addresses,  netmasks  (NM),  and  default  gateways  (DG),  used  in  creating  the 
simulation  model. 


Shore  Based  Server 
Fast  Ethernet 


•*;  131.120.122.120 
HM£55.255.25S.» 
DGrl  31.120.122.1 


Diagram:  By  LT  Joseph  Prrsella,  USH 
30  July,  IMS 


Figure  16.  Detailed  IP  Addressing  Including  Netmasks  and  Default  Gateways. 

All  IP  addresses  in  the  simulation  model  begin  with  131.120.  The  Advanced 
Networking  Laboratory  has  been  restricted  to  the  class  ‘C’  level  addresses  122.xxx  for 
Ethernet  networks  and  123.xxx  for  ATM  networks.  The  information  in  Figure  16  is  applied 
to  each  adapter  using  the  TCP/IP  properties  dialog  box  within  Microsoft  Windows  NT  4.0. 
Under  the  routing  tab  of  the  TCP/IP  properties  dialog  box,  ‘Enable  IP  forwarding’  has  been 
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selected  on  both  ELAN  server  and  router  LECs.  With  IP  forwarding  enabled,  TCP/IP  data 
packets  flow  through  both  server/router  edge  devices. 

Figure  17  is  a  basic  block  diagram,  which  illustrates  the  IP  addressing  as 
implemented  in  the  simulation  model. 


Shore  Based  Admiral*  Workstation  Shore  Based  Server 

OS:  Windows  NT  4.0  WoiKstation  OS:  Windows  HT  4.0  Server 


Diagram:  By  LT  Joseph  Prisella,  USH 
30  July,  1009 


Figure  17.  Basic  IP  Address  Block  Diagram. 


Microsoft’s  updated  Routing  and  Remote  Access  Service  (RRAS)  version  2 
software  supports  Routing  Information  Protocol  version  2  (RIP-2).  The  key  advantage  to 
operating  RIP-2  is  the  ability  to  further  divide  class  “C”  addresses  into  smaller  subnets. 
RRAS  is  supported  only  by  Windows  NT  4.0  Server.  The  term  server/router  is  used  when 
discussing  the  ELAN  servers  as  only  servers  are  designed  to  support  the  RIP-2  compliant 
routing  service.  The  ship’s  ELAN  IP  addresses  are  restricted  to  the  128  upper  class  ‘C’  host 
addresses  through  the  use  of  the  network  mask  255.255.255.128.  All  devices  within  the 
ship’s  ELAN  including  the  ASX-200BX  switch  are  assigned  the  IP  address  range  123.128 
to  123.255.  The  shore’s  ELAN  IP  addresses  are  likewise  restricted  to  using  only  the  lower 
128  addresses  in  the  range  123.0  to  123.127,  using  the  same  subnet  mask.  Since  the  ship’s 
server/router  is  a  member  of  both  the  ship  and  shore  ELAN  as  discussed  in  the  data  link 
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layer  section,  it  is  assigned  IP  addresses  corresponding  to  each  subnet.  Figure  18  uses  the 
DPConfig  command  to  display  the  configuration  of  the  ship’s  server/router. 


|**'5  Command  Prompt 

@0Q 

IMicrosoft(R)  Windows  NT( TM) 

|(C)  Copyright  1985-1996  Microsoft  Corp. 

□ 

M:\>ipconf ig 

Windous  NT  IP  Conf  igurat  ion 

Ethernet  adapter  F0RELAN4: 

IP  Address.  -  . 

131.120.123.131 

Subnet  Mask  . 

255.255.255.128 

Default  Gateway  . 

Ethernet  adapter  F0RELAN3: 

IP  Address . 

Subnet  Mask  . 

Default  Gateway  . 

131. 120. 123. ?h 

255.255.255.128 

131. 120.123. 22 

Figure  18.  IPConfig  of  the  Ship’s  Server/Router. 


The  shore  server/router  was  also  upgraded  to  operate  the  current  RRAS  version. 
The  reason  for  the  upgrade  differs  from  that  of  the  ship’s  server/router.  The  shore 
server/router  could  effectively  use  RIP-1  to  route  TCP/IP  packets  within  its  domain  as  the 
router  crosses  the  122  and  123  subnets  meeting  RJP-1  requirements.  The  reason  then  lies  in 
the  ability  to  forward  TCP/IP  packets  from  the  ship’s  CO’s  workstation  to  the  internet.  In 
order  to  accomplish  this,  all  routers  along  the  route  must  support  RIP-2,  or  no  IP  packet 
forwarding  can  be  accomplished. 

As  previously  stated,  IP  packet  forwarding  is  enabled  at  both  server/routers.  Each 
server/router  is  also  the  designated  default  gateway  for  their  respective  ELAN.  This  means 
that  all  ship  workstations  must  have  the  ship’s  server/router  IP  address  entered  in  the  default 
gateway  section  of  the  Microsoft  TCP/IP  properties  dialog  box,  IP  address  tab,  as  displayed 
in  Figure  19. 
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Figure  19.  TCP/IP  Properties  Dialog  Box,  IP  Address  Tab,  Ship-to-Ship. 

Figure  20  illustrates  the  IP  address  settings  for  the  ship’s  server/router  properties  as  a 
member  of  the  ship’s  ELAN. 


Figure  20.  TCP/IP  Properties  Dialog  Box,  IP  Address  Tab,  Ship-to-Shore. 


In  the  same  way  a  ship’s  workstation  addresses  the  ship’s  server/router,  the  ship’s 
server/router  addresses  the  shore’s  server/router.  Looking  from  the  shore  ELAN  to  the  ship 
ELAN,  the  ship’s  server/router  appears  to  the  shore’s  server/router  as  just  another 
workstation  with  an  assigned  IP  address  and  knows  nothing  of  the  network  hidden  behind 
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the  ship’s  server/router.  Figure  21  illustrates  the  establishment  of  static  routes  ensuring 
proper  IP  traffic  flow  to  and  from  respective  gateways  when  using  RRAS. 


Is.  Routing  and  RAS  Admin  -  WNETLABSVR 1 01 

MR£3|| 

Serve*  Qptiom  Iocb  fydions 

a* 

Ui 

^\\NETIA8$VR101 

••]*£  LAN  and  Demand  Dial  Interface* 

1  B  IP  Routing 

Summery 

RIP  for  Internet  Protocol 

Active  Connections  and  Pods 

Destination 

{  Network  mask 

j  Gateway 

1  interface 

1  Metric 

13U20L123.O 

131.120.123.128 

255255355.128 

255.255.255.128 

131.120.123.22 
131.120 12324 

13]  ForeRurmer  ELAN  Adapter  {ihoce) 
P]  ForeRurmer  ELAN  Adapter  (shore) 

.1  ;  :- 

1 

Figure  21.  Static  Routing  Dialog  Box. 

IP  addressing  does  not  only  apply  to  Microsoft  NT  workstations  and  servers  as 
studied  above,  but  in  much  the  same  way  the  ASX-200  BX  was  assigned  as  a  LEC,  it  too 
can  be  assigned  an  IP  address.  The  assigning  of  IP  addresses  to  the  ATM  switches  enables 
administrators  to  telnet  into  the  switch  via  remote  location.  This  function  allows  them  to 
remotely  load,  control  and  monitor  the  operation  of  the  ATM  switch  instead  of  having  to  log 
on  locally  to  the  console  port  of  the  switch.  Once  an  IP  address  is  assigned,  the  ASX-200 
BX  appears  to  any  workstation  within  the  network  as  another  LEC. 

Figure  22  is  the  result  of  typing  the  configuration  IP>  show  command  within  the 
shore  assigned  ASX-200  BX.  The  ship  configuration  is  nearly  identical  with  the  exception 
that  el  16  is  replaced  as  shown  in  Table  2.  In  both  instances,  the  IP  forwarding  state  is  set  to 
forwarding.  To  check  the  switch  IP  environment,  the  command 

configuration  ip  route>sh 

is  entered  and  reveals  the  details  shown  in  Table  3  and  Table  4.  The  G  flag  in  the  tables 
means  that  it  is  an  indirect  route  to  a  gateway  [11],  By  setting  the  default  destination  value 
to  the  respective  ship  or  shore  gateway,  all  IP  traffic  is  routed  to  the  appropriate 
server/router. 
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£<«Ct  if# 


j Opening  a  session  for  ••127-0.0.1",  please  wait... 
Connected  to  "127.0.0.1"  (asx200bx). 


NETLABSW20: :>  con 


NETLABSW20: :conf iguration>  ip 
|NETLflBSW20: : configuration  ip>  sh 


interface  state 


address  netnask  broadcast  mtu 
127.0.0.1  255.0.0.0  N/A  H096 
131.120.123.160  255.255.255.128  131.120.123.255 


131.120.123.20  255.255.255.128  131-120.123-127  1500 


IP  Forwarding  State:  forwarding 
NETL ABSU2  0 : : configuration  ip> 


Figure  22.  Shore  ASX-200BX  Assigned  IP  Addresses. 


Interface  State  Address  Netmask  Broadcast  MTU 

ell7  up  131.120.123.130  255. 255. 255;  128  131.120.123.255  1500 

Table  2.  Ship  ASX-200BX  Assigned  DP  Addresses. 

Destination  Gateway  Metric  Interface  Flags 

default . . . 131.120.123.22  1  ell6  G 

127.0.0.1  127.0.0.1  0  loO 

131.120.123.0  131.120.123.20  0  ell6 

Table  3.  Shore  ELAN  IP  Routing  Information. 

Destination  Gateway  Metric  Interface 

default"  131.120.123.131  1  ell7 

127.0.0.1  127.0.0.1  0  loO 

131.120.123.128  131.120.123.130  0  el  17 

Table  4.  Ship  ELAN  DP  Routing  Information. 

This  concludes  discussion  of  the  network  layer.  In  this  chapter,  we  have  discussed 
the  physical  layer,  data  link  layer  and  the  network  layer.  At  this  point,  the  simulation  model 
is  defined  and  ready  for  testing. 
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rv.  ANALYSIS  OF  DATA  THROUGHPUT  OVER  AN  ATM  WAN 


In  Chapter  HI,  we  established  a  ship-to-shore  simulation  model,  and  Figure  11  and 
Figure  12  illustrated  the  layout  for  the  single  and  two  (split)  ELAN  configurations, 
respectively.  Figure  9  focused  on  an  inport  situation  where  a  ship  ATM  ELAN  was 
connected  directly  to  a  shore  ELAN.  A  second  shore  server  using  a  100  Mbps  Fast  Ethernet 
connection  was  also  connected  to  the  shore  server.  This  chapter  discusses  in  detail  analysis 
setup,  analysis  of  inport  test  results,  and  analysis  of  underway  test  results. 


A.  ANALYSIS  SETUP 


Two  software  programs  were  essential  in  developing  the  test  results.  The  first 
program  was  a  generic  echo  server  [12],  which  was  started  on  the  shore  server/router.  The 
echo  server’s  purpose  was  to  provide  a  means  of  replicating  packets  sent  from  a 
workstation.  The  second  program.  Socket  Wrencher  [13],  was  configured  to  transmit  and 
receive  TCP  packets  and  determine  throughput  calculations.  Socket  Wrencher’ s 
configuration  dialog  box,  as  displayed  in  Figure  23,  permits  the  user  to  input  the  IP  address 
of  the  device  operating  the  echo  server. 


Configure 


Host: 


131.120.122.101 


iteration: 


100 


-Transmit  Bytes 

C  128  KByte 
O  64  KByte 
C 1  KByte 


OK 

Cancel 


Figure  23.  Socket  Wrencher  Configuration  Dialog  Box.  [13] 

All  trials  conducted  used  the  shore’s  server/router.  When  testing  the  ATM  ELANS, 
the  “Host”  block  was  set  to  IP  address  131.120.123.21  whereas  testing  for  the  Fast  Ethernet 
connection  was  directed  to  IP  address  131.120.122.101.  Trials  with  propagation  delay 
greater  than  5  ms  were  run  for  20  iterations  while  all  other  trials  were  tested  at  100 
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iterations.  The  “Transmit  Bytes”  block  indicated  the  amount  of  data  (or  file  size)  to  send  to 
the  echo  server  in  one  iteration.  Experiments  were  conducted  with  transmission  sizes  of  1 
MB,  128  KB,  or  64  KB. 

The  next  step  in  performing  a  Socket  Wrencher  test  was  to  select  the  TCP  echo 
synchronous  test  icon,  which  then  displayed  the  dialog  box  as  in  Figure  24. 


TCP  Echo  Synchronous  Test 


TCP  Echo  Synchronous  Test 

Buffer  size  • 


:  jk 

2K 

— 

8K 

ESI 

: '  lei< 

- , - 

56 

- 1 - TT - : - H  ■ 

112  168  225 

Kbytes  per  second 

i-H  This  Computet  ■ 

H  NetManage  50  MHz  Version  4.81  April  1934 

[Irani  ' 

Figure  24.  Socket  Wrencher  TCP  Echo  Synchronous  Test  Dialog  Box.  [13] 


Selection  of  the  “OK”  button  would  start  the  configured  trial  run.  Socket  Wrencher 
is  designed  to  return  values  for  each  of  the  window  sizes  as  displayed  in  Figure  24. 
Window  size  refers  to  the  number  of  bytes  that  the  receiver  is  willing  to  accept.  The  size  of 
the  receive  buffer  in  general  is  the  maximum  size  of  the  advertised  window  for  that 
connection.  By  default,  the  window  size  is  limited  to  a  16-bit  field,  which  limits  the 
window  size  to  65535  bytes  maximum[ll].  Window  size  throughout  for  this  thesis  is 
controlled  by  the  use  of  the  Socket  Wrencher  program.  The  Socket  Wrencher  program  is  an 
application,  which  is  capable  of  changing  the  socket  buffer  size  to  influence  performance. 
Due  to  problems  with  the  echo  service  application,  the  16-KB  window  buffer  failed  to 
function  correctly  during  testing  and  was  not  used.  The  raw  data  for  all  runs  is  contained  in 
Appendix  D.  Many  trials  used  the  same  Socket  Wrencher  configuration  while  varying  the 
propagation  delay.  Consequently,  the  TCP  synchronous  test  window  was  closed  after  each 
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trial  and  the  Socket  Wrencher  program  restarted  after  each  run.  The  purpose  for  the 
shutdown  and  restart  cycle  was  to  reset  Socket  Wrencher  after  aborting  the  program  when 
testing  went  to  the  16-KB  window  buffer  size. 

Propagation  delay  throughout  all  testing  was  solely  controlled  by  the  Adtech  SX-14 
data  channel  simulator  as  illustrated  in  Figure  11  and  Figure  12.  The  recording  of 
propagation  time  as  discussed  throughout  this  report  is  one  half  of  the  round  trip  time.  All 
trials  used  identically  set  W— >  E  and  E  — » W  propagation  delays  as  detailed  in  Appendix  D. 
The  largest  propagation  delay  tested  was  set  to  250  ms,  which  is  approximately  the 
propagation  delay  between  two  earth  stations  communicating  via  a  geosynchronous  satellite. 

In  summary,  throughput  calculations  displayed  on  the  TCP  echo  synchronous  trial 
dialog  box  were  calculated  in  the  following  manner: 

1.  The  workstations  running  Socket  Wrencher  generated  and  transferred  the 
configured  number  of  bytes. 

2.  The  packets  received  at  the  server  were  sequentially  ordered  and  sent  to  the  echo 
server  application  layer  program. 

3.  The  echo  server  regenerated  all  received  packets  and  echoed  them  back  to  the 
network  with  the  IP  address  of  the  originator. 

4.  The  originating  workstation,  through  the  use  of  the  Socket  Wrencher  program, 
received  all  packets  and  determined  the  throughput  for  the  selected  number  of 
iterations  based  on  the  elapsed  amount  of  time  it  took  to  receive  all  of  the  echoed 
transmitted  application  layer  data. 

B.  ANALYSIS  OF  INPORT  SCENARIO 

Appendix  E  contains  plots  for  the  three  different  transmitted  file  sizes  produced 
using  Socket  Wrencher  with  the  SX-14  propagation  delay  set  to  zero  for  the  inport  scenario. 
A  closer  analysis  of  the  1  MB  file’s  throughput  yields  some  interesting  results  as  detailed  in 
Figure  25.  Recall  that  the  inport  trial  was  conducted  using  a  single  or  a  split  ELAN  as  well 
as  a  100  Mbps  Fast  Ethernet  connection.  Figure  25  illustrates  that  the  throughput  of  100 
Mbps  Fast  Ethernet  rivals  that  of  a  single  ELAN  operating  an  OC-3  (155  Mbps)  connection. 
Further  analysis  of  plots  in  Appendix  E  indicates  that  the  same  is  true  for  the  128  KB  and 
the  64  KB  data  files  as  well.  The  split  ELAN  in  Figure  25  falls  short  in  throughput 
comparisons  against  the  single  ELAN  and  Fast  Ethernet.  The  best  explanation  for  the 
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shortcoming  of  a  split  ELAN  with  zero  propagation  delay  is  due  primarily  to  the  extra 
processing  time  required  to  transfer  TCP  packets  through  the  ship’s  server/router. 


lMyte<tta(ile«ize(ZeroPr«pcgtilcnNcy) 


Figure  25.  1MB  Data  File  [Zero  Propagation  Delay]. 

Recall  from  chapter  IV  section  A,  throughput  tests  using  Socket  Wrencher  require 
that  a  TCP  packet  be  transmitted,  received,  and  regenerated  at  the  server,  and  then  returned 
back  through  the  network.  In  the  split  ELAN,  a  single  packet  must  be  segmented  and 
reassembled  two  times  within  the  ship’s  server/router.  This  adds  processing  time,  which 
directly  influences  throughput  as  measured  by  Socket  Wrencher. 

Proof  of  this  processing  delay  can  be  observed  in  Figure  25  when  comparing  the 
single  ELAN  to  the  server-server  connection  In  this  trial.  Socket  Wrencher  is  run  on  the 
ship  server/router  and  connects  to  the  shore  server,  thus  bypassing  the  routing  function 
Chapter  HI  states  that  each  of  the  two  server/routers  functions  using  RRAS  version  2.  RRAS 
version  2  is  a  program  which  provides  software  routing.  Much  faster  hardware  routers  are 
available  though  not  studied  in  this  thesis.  A  hardware  router’s  throughput  capacity  could 
potentially  approximate  that  of  the  server-server  connection.  The  use  of  a  software  router 
establishes  a  worst  case  scenario.  Processor  speed  and  available  memory  also  play  a  role  in 
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determining  the  efficiency  of  software  routing.  Additionally,  the  split  ELAN  workstation 
traversed  two  ASX-200  BX  switches  in  reaching  the  server  whereas  the  single  ELAN 
workstation  shared  a  port  on  the  same  switch  as  the  server.  Figure  25  also  compares  the 
throughput  versus  window  buffer  size.  It  is  can  be  clearly  seen  that  window  buffer  size  is  an 
important  element  in  maximizing  throughput  during  inport  scenario. 

An  analysis  of  die  plots  in  Appendix  E  indicates  that  larger  files  are  better  able  to 
take  advantage  of  the  larger  window  buffer  size.  This  analysis  may  appear  to  be  skewed 
and  misleading;  however,  on  closer  examination,  smaller  file  size  throughput  is  more 
significantly  affected  by  the  TCP  requirement  of  “slow  start.”  Slow  start  is  defined  as  the 
rate  at  which  new  packets  should  be  injected  into  the  network  as  set  by  the  rate  of 
acknowledgements  returned  from  the  receiver  end. 

Slow  start  attaches  the  “congestion  window”  to  the  sliding  window.  The  congestion 
window  is  initialized  to  one  segment  length.  This  then  limits  the  window  size  to  one 
segment  no  matter  what  the  advertised  receive  window  buffer  size  is  initially  set  to.  By 
default,  the  sender  can  transmit  up  to  the  minimum  of  the  congestion  window  and  the 
advertised  window.  The  congestion  window  provides  flow  control  imposed  by  the  sender 
while  the  advertised  window  provides  flow  control  imposed  by  the  receiver. 

The  first  segment  is  transmitted,  and  the  sender  awaits  the  acknowledgement  from 
the  receiver.  Once  the  transmitter  receives  the  acknowledgement,  the  window  size  is 
incremented  to  two  segments.  When  each  of  the  two  segments  are  acknowledged  at  the 
transmitter,  the  window  is  doubled.  This  process  continues  until  the  window  buffer  size  is 
reached.  [11] 

Slow  start  has  more  of  an  effect  on  small  file  sizes  as  compared  to  larger  file  sizes. 
The  smaller  file  sizes  are  nearer  to  completion  on  exiting  slow  start  than  would  be  a  larger 
file  size,  which  is  allowed  to  operate  at  the  advertised  window  size. 

One  of  the  principal  questions  of  this  thesis  is  to  analyze  the  benefit  of  operating 
either  a  single,  split,  or  Fast  Ethernet  network.  The  inport  graphs  in  Appendix  E  suggest 
that  the  optimum  configuration  would  be  to  operate  all  ATM  LECs  on  a  single  El -AN  or 
Fast  Ethernet  LAN  when  transferring  “small”  files  using  an  8-KB  window  buffer;  however, 
an  important  factor  that  must  be  addressed  is  the  amount  of  overhead  data  required  to 
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transmit  TCP  data  over  ATM.  The  small  file  size  used  by  Socket  Wrencher  is  not  indicative 
of  the  benefits  of  using  ATM.  Much  of  the  reduction  in  throughput  is  attributed  to  call 
establishment  at  the  TCP  and  LANE  levels.  Additional  reduction  is  due  to  the  addition  of 
headers  and  segmentation  and  reassembly  at  the  ATM,  IP,  and  TCP  layers.  Call 
establishment  results  are  averaged  over  100  iterations  as  the  data  direct  VCC  discussed  in 
(see  Chapter  II)  is  not  dropped  until  all  100  iterations  are  complete. 


C.  ANALYSIS  OF  UNDERWAY  SCENARIO 

The  graph  of  underway  results  for  the  1MB  data  file  is  displayed  in  Figure  26.  The 
rapid  transition  in  throughput  in  the  0  to  5  ms  propagation  delay  range  is  clarified  in  Figure 

27.  Figure  27  illustrates  the  convergence  of  both  the  single  and  the  split  ELAN  as  well  as 
the  4-KB  and  8-KB  window  buffer  size.  Once  converged  at  the  5  ms  point,  all  four  plots 
follow  the  same  trend  in  throughput  out  to  250  ms  of  propagation  delay  as  shown  in  Figure 

28. 
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Figure  26.  Throughput  versus  Propagation  Delay  [0-250  ms]  of  a  1MB  Data  File. 
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Figure  27.  Throughput  versus  Propagation  Delay  [0-5  ms]  of  a  1MB  Data  File. 
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Figure  28.  Throughput  versus  Propagation  Delay  [50-250  ms]  of  a  1MB  Data  File. 
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Appendix  F  contains  graphs  of  all  underway  trials  conducted  for  all  three  file  sizes 
within  Socket  Wrencher.  In  all  cases,  the  throughput  for  single  and  split  ELANs  converges 
within  5  ms  of  propagation  delay  for  each  of  the  data  files  transferred. 

In  summary,  analysis  of  the  underway  trials  demonstrates  that  processing  delays 
become  insignificant  as  propagation  delay  becomes  more  dominant.  Note  that  a  5  ms 
propagation  delay  equates  to  1500  Km  or  approximately  a  900  mile  separation  between  ship 
and  server  stations.  Therefore,  for  ships  at  sea  out  past  the  line-of-sight  (LoS) 
communication  range,  the  benefit  of  a  single  ELAN  over  a  split  ELAN  has  been  overcome 
by  the  propagation  delay.  Consequently,  no  benefit  is  gained  by  placing  all  LECs  within  the 
same  ELAN. 
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V.  CONCLUSION 


A.  SUMMARY  OF  WORK 

The  purpose  of  this  thesis  was  to  design,  develop,  test  and  analyze  an  Emulated 
LAN  (ELAN)  system.  The  objectives  of  this  thesis  as  detailed  in  Chapter  I  were  to  establish 
a  working  ELAN  within  the  NPS  Advanced  Network  Laboratory,  to  determine  the  data 
throughput  using  various  network  designs,  and  to  identify  an  optimal  network  configuration. 

Chapter  II  laid  the  foundation  for  understanding  the  functionality  of  LANE.  This 
chapter  described  the  functions  of  each  major  component  of  LANE  and  how  they 
interoperate.  Chapter  HI  presented  the  implementation  of  a  working  ELAN.  Chapter  IV 
utilized  the  various  ELAN  implementations  in  Chapter  m  through  the  use  of  an  echo  server 
and  the  Socket  Wrencher  software  to  measure  throughput  values  for  both  “inport”  and 
“underway”  scenarios.  Results  of  these  measurements  are  presented  in  Chapter  IV, 
Appendix  E  and  Appendix  F  to  demonstrate  throughput  limitations  based  on  propagation 
delay,  process  delay,  window  buffer  size,  and  data  file  size. 

In  conclusion,  this  thesis  has  provided  measured  results  in  terms  of  throughput  for 
three  separate  scenarios.  As  presented  in  Chapter  IV,  a  network  using  software  routing  was 
the  worst-case  scenario..  Also,  if  more  advanced  hardware  routing  were  used,  results  similar 
to  those  observed  in  the  server-to-server  plot  within  Figure  25  could  be  obtained.  The 
recommendation  of  this  work  in  regards  to  connectivity  and  throughput  would  be  to  operate 
individual  units  as  members  of  a  split  ELAN  within  an  ATM  network  while  using  hardware 
internetwork  routing.  The  benefit  of  utilizing  this  configuration  would  be  easily  realized 
during  the  in-chop  process  as  only  a  single  router  would  require  address  modifications  as 
compared  to  an  entire  network. 

B.  FUTURE  WORK 

The  establishment  of  an  operational  split  ELAN  within  the  NPS  Advanced 
Networking  Laboratory  has  opened  the  door  to  several  future  thesis  projects.  Some  of  the 
possible  future  studies  are  listed  below: 
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1.  The  use  of  the  Socket  Wrencher  program  in  calculating  throughput  was  very 
limiting  in  the  area  of  file  size.  Using  the  underway  split  ELAN  scenario  and  the 
lab’s  EtherPeek  network  analysis  software,  a  future  investigation  could 
determine  throughput  versus  propagation  delay  of  a  VTC  or  streaming  video 
source.  The  Advanced  Networking  Laboratory  is  outfitted  with  two  Logitech 
QuickCam  Pro  web  cameras  to  facilitate  this  study. 

2.  The  available  equipment  within  the  Advanced  Networking  Laboratory  provides 
an  excellent  setting  to  study  the  “man  in  the  middle  attack.”  Through  the  use  of 
the  networking  equipment,  a  miniature  Internet  could  be  configured  to  allow  the 
testing  and  analysis  of  this  attack. 

3.  ASX-200BX  ATM  switches  provide  an  administrator  the  ability  to  establish 
“usage  parameter  controls.”  An  exploration  in  configuration  and  optimization 
could  be  implemented  in  the  ship  and  shore  ELANs.  Testing  conducted 
throughout  this  thesis  was  under  optimal  conditions.  Further  study  could 
incorporate  the  use  of  the  Adtech  AX-4000  generator  functions  to  add  “bursty 
traffic”  into  the  scenario  and  determine  the  throughput  in  a  “noisy”  environment. 

4.  A  computer  simulation  model  of  the  system  described  within  this  thesis  can  be 
developed  and  throughput  calculations  compared  to  those  in  Appendix  D. 
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RMKS/1 .  THIS  IS  THE  FIRST  IN  A  SERIES  OF  JOINT  CINCPACFLT  AND  CINCLANTFLT  MESSAGES  CONCERNING  THE 
DEVELOPMENT  AND  IMPLEMENTATION  OF  IT-21 .  THIS  MESSAGE  PROVIDES  IT-21  HARDWARE/SOFTWARE 
IMPLEMENTATION  STANDARDS  FOR  PROGRAMS  INSTALLING  INFORMATION  SYSTEMS  ON  FLEET  UNITS/BASES  AND 
PROVIDES  THE  FLEET  WITH  GUIDANCE  ON  MAINTAINING  EXISTING  INFORMATION  SYSTEMS  UNTIL  INSTALLATION 
OF  IT-21  PRODUCTS.  THE  IT-21  IMPLEMENTATION  STANDARDS  OUTLINED  BELOW  ARE  PROMULGATED  IN  ADVANCE 
OF  DON-WIDE  GUIDANCE  FROM  THE  DON  CHIEF  INFORMATION  OFFICER  (CIO).  THE  DON  CIO  WILL  PROMULGATE 
DON-WIDE  STANDARDS  FOLLOWING  NEGOTIATION  OF  ENTERPRISE-WIDE  NETWORK  OPERATING  SYSTEMS  AND 
APPLICATIONS. 

2.  BACKGROUND:  INFORMATION  SUPERIORITY  IS  THE  FOUNDATION  OF  JOINT  VISION  2010  BATTLEFIELD 
DOMINANCE,  AS  WELL  AS  THE  WARFIGHTING  VISION  FOR  EACH  SERVICE.  NETWORK  WARFARE,  ROBUST 
INFRASTRUCTURE  AND  INFORMATION  DISSEMINATION  TO  DISPERSED  FORCES  ARE  KEY  ELEMENTS  IN  ACHIEVING 
INFORMATION  SUPERIORITY.  IT-21  IS  A  FLEET  DRIVEN  REPRIORITIZATION  OF  C4I  PROGRAMS  OF  RECORD  TO 
ACCELERATE  THE  TRANSITION  TO  A  PC  BASED  TACTICALTACTICAL  SUPPORT  WARFIGHTING  NETWORK.  THE 
INACTIVATION  OF  THE  CURRENT  DOD  MESSAGING  SYSTEM  (AUTODIN)  BY  DEC  99,  WITH  NO  PLANNED  NAVY 
INFRASTRUCTURE  REPLACEMENT,  MANDATES  THE  RAPID  IMPLEMENTATION  OF  THIS  WARFIGHTING  NETWORK 

3.  COMMERCIAL  NETWORK  OPERATING  SYSTEMS  (NOS)  AND  E-MAIL  PRODUCTS  HAVE  ACHIEVED  FUNCTIONAL 
PARITY.  THE  FLEETS  CANNOT  CONTINUE  TO  SUPPORT  A  MULTITUDE  OF  DIVERSE  OPERATING  SYSTEMS  AND  E- 
MAEL  PRODUCTS  WITH  THEIR  OWN  TRAINING,  OPERATIONAL  PROCEDURES  AND  TROUBLESHOOTING 
REQUIREMENTS.  THE  DOD  JOINT  TECHNICAL  ARCHITECTURE  (JTA)  AND  DEFENSE  INFORMATION  INFRASTRUCTURE 
COMMON  OPERATING  ENVIRONMENT  (DR  COE)  PROVIDE  DOD  WITH  THE  AIS  SYSTEM  GUIDANCE  REQUIRED  TO 
TAKE  THE  NAVY  INTO  THE  21st  CENTURY.  THIS  CONVERGENCE  OF  SOLUTIONS,  PROBLEMS  AND  GUIDANCE 
PROVIDES  THE  IMPETUS  TO  ESTABLISH  MINIMUM  NAVY  AIS  STANDARDS  AT  THIS  TIME.  IMPLEMENTATION  OF  THIS 
POLICY  REQUIRES  ALL  NON-STANDARD  NOS  AND  E-MAIL  PRODUCTS  BE  REPLACED  NLT  DEC  99. 
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A.  WINDOWS  NT  SERVER  4.0  IS  THE  STANDARD  FLEET  NOS.  IT  WILL  SOON  BE  FOLLOWED  BY  WINDOWS  NT  5.0. 
WINDOWS  NT  SERVER  4.0  IS  DEE  COE  COMPLIANT. 

B.  MS  EXCHANGE  IS  DESIGNATED  AS  THE  STANDARD  E-MAIL  SOLUTION  FOR  BOTH  FLEETS  TO  ENSURE  AN 
INTEROPERABLE  SECURE  MESSAGING  SYSTEM  IS  OPERATIONAL  PRIOR  TO  AUTODIN  INACTIVATION  NLT  DEC  99. 

C.  MS  OFFICE  97  IS  DESIGNATED  AS  THE  STANDARD  FLEET  OFFICE  SOFTWARE. 

D.  EXPENDITURE  OF  OPERATING  FUNDS  TO  MAINTAIN  EXISTING  IT-21  NONCOMPLIANT  NOS  AND  APPLICATIONS 
SHALL  BE  THE  ABSOLUTE  MINIMUM  NECESSARY  TO  MEET  OPERATING  REQUIREMENTS  UNTIL  IT-21  NOS/SOFTWARE 
IS  INSTALLED  EVEN  IF  TEMPORARY  LN  DEGRADATION  OCCURS.  SOFTWARE  REQUIREMENTS  DRIVE  HARDWARE 
STANDARDS.  HARDWARE  AND  SOFTWARE  PURCHASED  TODAY  MUST  BE  CAPABLE  OF  MEETING  MISSION 
REQUIREMENTS  THROUGH  THE  YEAR  2000. 

4.  CINCPACFLT  AND  CINCLANTFLT  ARE  ACTIVELY  WORKING  WITH  OPNAV  ON  IT-21  FUNDING  AND 
IMPLEMENTATION  PLANS.  IN  GENERAL,  AFLOAT  IT-21  IMPLEMENTATION  WILL  BE  LINKED  TO  DEPLOYING 
BATTLEGROUPS  AND  ASHORE  IT-21  WILL  BE  IMPLEMENTED  IN  A  PHASED  APPROACH.  SPECIFIC  IMPLEMENTATION 
SCHEDULES  WILL  BE  PROMULGATED  AT  A  LATER  DATE.  CINCPACFLT  AND  CINCLANTFLT  ARE  TRANSITIONING  TO 
WINDOWS  NT  4.0,  MS  EXCHANGE  AND  MICROSOFT  OFFICE  97.  THIS  ENVIRONMENT  CANNOT  BE  OPTIMIZED 
WITHOUT  32  BIT  OPERATING  SYSTEMS,  HIGH  RESOLUTION  DISPLAYS  AND  MASS  STORAGE.  ATM  BACKBONE  LANS 
WITH  AT  LEAST  100  MBS  (TCP/IP)TO  THE  DESKTOP  PC  WILL  BE  INSTALLED  ON  ALL  SHIPBOARD  LANS,  FLEET 
HEADQUARTERS  (CPF,  CLF,  TYCOMS,  GROUP  AND  SQUADRON  COMMANDS)  AND  SHOULD  BE  INSTALLED  IN  THOSE 
SHORE  ACTIVITIES  THAT  SUPPORT  TACTICAL  OPERATIONS.  THIS  WILL  THEN  ALLOW  TRANSITION  TO  ATM-TO-  THE- 
DESKTOP  PC  WHEN  THE  ATM  TECHNOLOGY  MATURES. 

5.  SYSTEM  COMMANDS  AND  PROGRAM  MANAGERS: 

A.  NTCSS  WILL  BECOME  THE  IT-21  PROGRAM  OF  RECORD  FOR  INSTALLATION  OF  BOTH  SECRET  AND 
UNCLASSIFIED  LANS  ONBOARD  COMMISSIONED  SHIPS.  NTCSS  (ATIS/SNAP  III)  LANS  INSTALLED  FROM  THIS  POINT 
ON  WELL  HAVE  AN  ATM  BACKBONE,  100  MBS  (FAST  ETHERNET)  TO  THE  DESKTOP  PC  AND  THE 
HARDWARE/SOFTWARE  OUTLINED  AT  THE  END  OF  THIS  MESSAGE.  THE  MIGRATION  OF  NTCSS  LANS  TO  HIGHER 
CAPACITY  LANS  WELL  REDUCE  THE  NUMBER  OF  PC’S  DELIVERED  DURING  INITIAL  INSTALLATION.  THE  TRADE-OFF 
OF  QUANTITY  FOR  FRONT  END  PC’S  IS  REQUIRED  TO  SUPPORT  JV-2010  AND  AUTODIN  INACTIVATION. 

B.  SPAWAR  IS  WORKING  WITH  NAVSEA  TO  ENSURE  THAT  LANS  INSTALLED  DURING  NEW  CONSTRUCTION  MEET 
THE  rr-21  REQUIREMENTS. 

C.  APPLICATION  PROGRAM  MANAGERS  SUCH  AS  JMCIS,  NSEPS,  TAMPS,  AND  GCSS  SHOULD  MIGRATE  CURRENT 
APPLICATIONS  TO  THE  DII  COE  WITH  AN  IMMEDIATE  OBJECTIVE  OF  OBTAINING  PC  WORKSTATION  ACCESS  TO  ALL 
APPLICATION  DATA  ON  AN  ENTERPRISE  LAN. 

D.  PROGRAMS  INSTALLING  INFORMATION  SYSTEMS  (NEWNET,  SMARTLINK,  SMARTBASE,  TELEMEDICINE,  ETC.) 
MUST  INSTALL  COMPONENTS  IN  FLEET  ACTIVITIES  THAT  MEET  IT-21  STANDARDS  AND  PROVIDE 
INTEROPERABILITY  THROUGHOUT  THE  WARFIGHTING  NETWORK. 

6.  TYCOMS  AND  THIRD  ECHELON  COMMANDS  SHALL  ENSURE  THAT: 

A.  SHIPS  AND  ACTIVITIES  INSTALLING  NEW  LANS,  UNDERGOING  SIGNIFICANT  LAN  UPGRADES  OR  THOSE 
ACTIVITIES  WITH  STAND  ALONE  PC’S  SHALL  INSTALL  IT-21  HARDWARE  AND  SOFTWARE.  NEW  OR  REPLACEMENT 
SHIPBOARD  AND  SHORE  BASED  TACTICAL  LANS  SHOULD  HAVE  AN  ATM  BACKBONE  WITH  AT  LEAST  100  MBS  (FAST 
ETHERNET)  TO  THE  PC. 

B.  SHIPS  AND  ACTIVITIES  WITH  EXISTING  LANS,  WHICH  REQUIRE  REPLACEMENT  OF  UNSERVICEABLE 
HARDWARE,  SHORT  OF  A  FULL  NETWORK  UPGRADE,  SHALL  INSTALL  HARDWARE  WHICH  MEETS  IT-21  STANDARDS. 
THE  NEW  EQUIPMENT  MAY  NOT  BE  COMPATIBLE  WITH  THE  EXISTING  LAN  HARDWARE.  CINCPACFLT  AND 
CINCLANTFLT  BELIEVE  THAT  ALL  AUTOMATED  INFORMATION  SYSTEMS  (AIS)  PROCURED  MUST  BE  COMPATIBLE 
WITH  THE  IT-21  LAN  STANDARDS  EVEN  IF  TEMPORARY  LAN  DEGRADATION  OCCURS.  THERE  IS  ONLY  SUFFICIENT 
FUNDING  TO  DO  IT  RIGHT  THE  FIRST  TIME. 

7  THE  H-21  STANDARDS  BELOW  REPRESENT  FRONT  END  MARKET  TECHNOLOGY,  ARE  DYNAMIC  IN  NATURE,  AND 
WELL  CONTINUE  TO  BE  CLOSELY  LINKED  TO  COMMERCIAL  TRENDS.  THE  STANDARDS  LISTED  BELOW  ARE 
INTENDED  TO  BE  MINIMUM  STANDARDS  AND  WILL  BE  UPDATED  PERIODICALLY. 

A.  IT-21  LAN: 

(1)  AFLOAT  LAN  STANDARDS  -  ATM  FIBER  BACKBONE,  100  MBPS  (FAST  ETHERNET)  TO  THE  PC. 

(2)  ASHORE  TACTICAL  AND  HEADQUARTERS  COMMAND  CENTER  STANDARD  (CPF,  CLF,  TYCOMS,  GROUP  AND 
SQUADRON  COMMANDS)  -  ATM  BACKBONE,  100  MBPS  (FAST  ETHERNET)  TO  THE  PC. 

(3)  ASHORE  TACTICAL  SUPPORT  COMMAND  STANDARDS  (BASES)  -  ATM  BACKBONE,  100  MBPS  (FAST  ETHERNET) 
TO  THE  PC. 

(4)  METROPOLITAN  AREA  NETWORKS  (MAN)  SHOULD  BE  CAPABLE  OF  SUPPORTING  AT  LEAST  OC-3  (155MBS). 

B.  IT-21  SOFTWARE: 

-  WINDOWS  NT  4.0/5.0  WORKSTATION 

-  MS  OFFICE  97  PROFESSIONAL  (WORD  97,  POWERPOINT  97,  EXCEL  97,  S 
ACCESS  97) 

-  IBM  ANTI  VIRUS  (NAVY  LICENSE,  AVAIL  FROM  NAVCIRT) 

-  MS  BACK  OFFICE  CLIENT 
-MS  OUTLOOK 97 

-MS  EXCHANGE  5.0 
-MS  IMAGE  COMPOSER 
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C.  rr-21  DATABASES.  RELATIONAL  DATABASES  THAT  CAN  SUPPORT  WEB  TECHNOLOGY  IAW  THE  COE  (ORACLE, 
SYBASE,  SQL  SERVER,  ACCESS,  ETC.)  WILL  BE  USED  TO  SUPPORT  DATA  REQUIREMENTS  AND  APPLICATION 
DEVELOPMENT.  ALL  PROCESS  ENGINEERING  INITIATIVES  THAT  RESULT  IN  DESIGN/REDESIGN  OF  A  DATA 
COLLECTION/CAPTURE  SYSTEM  MUST  USE  COE  COMPLIANT  RELATIONAL  DATABASE  MANAGEMENT  SYSTEMS 
(RDBMS)  SOFTWARE.  THIS  REQUIREMENT  IS  PROVIDED  TO  ENSURE  RDBMS  INITIATIVES  USE  COTS  APPUCATION 
SOFTWARE.  FOR  ADDITIONAL  INFORMATION  ON  RELATIONAL  DATABASES  CONTACT  CDR  SANDY  BUCKLES,  CPF 
N67,  COMM/DSN  (808)  474-6384,  NIPRNET  mailto:U67@CPF-EMH.CPF.NAVY.MIL. 

D.  MINIMUM  IT-21  PC  CAPABILITIES:  CPF  CAN  CURRENTLY  PURCHASE  THE  IT-21  STANDARD  PC  WITH  SOFTWARE 
FOR  $3250.00  -  $3579.00  -  SEE  PARA  7(H)  AND  7(1). 

-  200  MHZ  PENTIUM  PRO  CPU 
-64  MB  EDO  RAM 

-3.0  GB  HARD  DRIVE 

-  3.5  INCH  FLOPPY  DISK  DRIVE 

-  8X  IDE  CD-ROM 

-  DUAL  PCMCIA/PC  CARD  READER 

-  PCI  VIDEO  W/2MB  RAM 

-  17  INCH  MONITOR  (1280  X  1024) 

-  POINTING  DEVICE  (TRACKBALL  OR  MOUSE) 

-  SOUNDBLASTER  (COMPATIBLE)  AUDIO  CARD  WITH  SPEAKERS  KEYBOARD 

-  CPU  COMPATIBLE  100  MBPS  FAST  ETHERNET  NIC 

E.  STANDARD  IT-21  LAPTOP  WORKSTATION:  APPROXIMATELY  $5300 - 
SEE  PARA  7(H). 

- 150  MHZ  PENTIUM 
-32  MB  EDO  RAM 

- 12.1  IN  SVGA  ACTIVE  MATRIX  COLOR  DISPLAY 
-2.1  GB  EIDEHDD 

-  6X  INTERNAL  CD-ROM 

-  MODEM,  PCMCIA  SLOTS,  NIC  CARD 

-  SMART  LITHIUM  BATTERY 

F.  rr-21  NT  FILE  SERVER  FOR  DIRECTORY  NETWORK  SERVICE:  APPROXIMATELY  $26K-  SEE  PARA  7(H).  THESE  ARE 
MINIMUM  SPECIFICATIONS .  NEEDS  OF  THE  SPECIFIC  NETWORK  WILL  DICTATE  REQUIREMENTS. 

-  DUAL  166  MHZ  PENTIUM  CPU 

-  5 12K  SECONDARY  CACHE  MEMORY-  256  MB  RAM 
-TWO  4  GB  SCSI  HDD 

-ONE  6  GB  DAT  DRIVE 

-  ONE  3.5  INCH  FLOPPY  DISK  DRIVE 
-6X  SCSI  CD-ROM 

-  DUAL  PCMCIA/PC  CARD  READER 

-  2  DPT  SCSI  III  CACHING  CONTROLLERS  (SMARTCACHE  4) 

-  PCI  VIDEO  W/2MB  RAM 

-  17  INCH  MONITOR  (1280  X  1024) 

-  POINTING  DEVICE  (TRACKBALL  OR  MOUSE) 

-  KEYBOARD 

-  TWO  CABLETRON  CPU  COMPATIBLE  ATM  NIC  CARDS 

ANTEC  DUAL  POWER  SUPPLY  CASE  (HOT  SWAPPABLE) 

G.  rr-21  FILE  SERVER/APPLICATION  SERVER:  APPROXIMATELY  $26K  -  SEE  PARA  7(H).  SAME  AS  IT-21  NT  FILE 
SERVER  FOR  DIRECTORY  NETWORK  SERVICE  WITH  THE  FOLLOWING  CHANGES: 

-  CHANGE  HDD  RQRMT  TO  FIVE  4  GB  DRIVES 

-  CHANGE  DAT  TO  18  GB. 

H.  PRICES  FOR  PC  TECHNOLOGY  ARE  CONSTANTLY  CHANGING  AND  CAN  VARY  GREATLY  DEPENDING  ON 
METHOD  OF  PROCUREMENT.  FOR  EXAMPLE,  ON  28  MAR  97  AN  IT-21  PC  PURCHASED  DIRECTLY  FROM  A  VENDOR 
COSTS  $3643.  GOVERNMENT  RATE  FOR  SMALL  PURCHASES  (LESS  THAN  TEN)  IS  $3579.  A  BULK  PROCUREMENT  (MORE 
THAN  SEVENTY-FIVE)  COSTS  $3250.  THE  ABOVE  PRICES  INCLUDE  SHIPPING.  BULK  PROCUREMENTS  SHOULD  BE 
MADE  THROUGH  THE  TYPE  COMMANDERS  WHEN  APPROPRIATE.  MR.  RICK  KOOKER,  CPF  N65,  COMM/DSN08O8)  474- 
5882,  NIPRNET:  U65@CPF-EMH.CPF.NAVY.MIL  IS  AVAILABLE  TO  ASSIST  TYCOMS  WITH  AIS  PROCUREMENT  ISSUES. 

I.  AS  NETWORK  COMPUTER  TECHNOLOGY  EVOLVES  SOME  COMMANDS  MAY  BE  ABLE  TO  TRANSITION  TO 
NETWORK  COMPUTERS.  WHEN  CONSIDERING  INSTALLATION  OF  NETWORK  COMPUTERS,  TOTAL  NETWORK  COST 
MUST  BE  EVALUATED.  NETWORK  COMPUTERS  HAVE  NOT  MATURED  SUFFICIENTLY  TO  IMPLEMENT  THEM  IN  FLEET 
PLATFORMS  AT  THIS  TIME. 

8.  WAIVER  REQUESTS  FROM  THE  ABOVE  STANDARDS  SHOULD  BE  SUBMITTED  DIRECTLY  TO  THE  RESPECTIVE 
CPF/CLF  N6.  POINTS  OF  CONTACT  ARE  AS  FOLLOWS: 

A.  CINCLANTFLT:  CDR  DEBRA  STRAUB  AT  COMM  (757)  322-5863,  NIPRNET:  mailto:U6@CLFNAVY.ME. 

B.  CINCPACFLT:  CDR  MIKE  SCOTT  AT  COMM  (808)  474-7860,  NIPRNET :U6 @ CPF-EMH.CPF.NAVY.MILy/ 

BT 

#9842 

NNNN 
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APPENDIX  B.  LECS  CONFIGURATION  FILE,  LECS.CFG 


# 

#  The  search  ordering  of  ELAN  names 

# 


Match.  Ordering:  shore,  ship 

# 

.Maximum_Frame_Size:  1516 

# 


shore.Accept:  xx.xxxx.xx.xxxxxx.xxxx.xxxx.xxxx.xxxxxxxxxxxx.xx 

shore.Address:  47.0005.80.FFE100.0000.F21A.44A2.0020481A44A2.01 

shore.BUS_Address:  47.0005.80.FFE100.0000.F21A.44A2.0020481A44A2.01 
shore.LAN_Name:  shore 

# 


ship.Accept: 
ship.  Address: 
ship.BUS_Address: 
ship.LAN_Name: 


xx.xxxx.xx.xxxxxx.xxxx.xxxx.xxxx.xxxxxxxxxxxx.xx 
47.0005.80.FFE100.0000.F21A.3E9A.0020181A3E9A.02 
47 .0005 . 80.FFE 1 00.0000 .F2 1  A.3E9  A.0020 181 A3E9  A.02 
ship 
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APPENDIX  C.  ASX-200BX  COMMAND  LINE:  CONFIGURATION  LANE 

LES>SHOW  ADVANCED 

NETLABSW20::configuration  lane  les>  sh  advanced 
ELAN  Name:  "shore" 

LES:  47 .0005 . 80.FFE 1 00.0000.F2 1  A.44A2. 002048 1 A44A2.0 1 
BUS:  47.0005 . 80.FFE 1 00.0000.F2 1  A.44A2. 002048 1 A44A2 .0 1 


LAN  Type:  Ethemet/IEEE  802.3  Maximum  Data  Frame  Size:  1516 

Non-proxy  Control  Distribute  VCC:  0.74 
Proxy  Control  Distribute  VCC:  -.- 
Multicast  Forward  VCC:  0.76 

Number  of  local  clients:  4 

LEC  #1  at  47.0005 . 80.FFE 1 00.0000.F2 1  A.44  A2.00204804EC43 .00  (vl, non-proxy) 
00-20-48-04-EC-43  ->  47.0005.80.FFE100.0000.F21A.44A2.00204804EC43.00 
Control  Direct  VCC:  0.73 

LEC  #2  at  47.0005 . 80.FFE 1 00.0000 .F2 1  A.44  A2 .00204804ED54.0 1  (vl, non-proxy) 
00-20-48-04-ED-54  ->  47.0005.80.FFE100.0000.F21  A.44A2.00204804ED54.01 
Control  Direct  VCC:  0.78 

LEC  #3  at47.0005.80.FFE100.0000.F21A.3E9A.00204804EA93.02  (vl, non-proxy) 
00-20-48-04-EA-93  ->  47.0005.80.FFE100.0000.F21  A.3E9A.00204804EA93.02 
Control  Direct  VCC:  0.80 

LEC  #4  at  47.0005. 80.FFE 1 00.0000.F2 1  A.44  A2.002048 1 A44A2. 1 0  (vl, non-proxy) 
00-20-48-1 A-44-A2  ->  47.0005.80.FFE100.0000.F21A.44A2.0020481A44A2.10 
Name:  SHORE 
Control  Direct  VCC:  0.85 
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ELAN  Name:  "ship" 

LES:  47.0005 .80.FFE 1 00.0000.F2 1  A.3E9A.002048 1 A3E9  A.02 
BUS:  47.0005.80.FFE100.0000.F21A.3E9A.0020481A3E9A.02 
LAN  Type:  Ethemet/IEEE  802.3  Maximum  Data  Frame  Size:  1516 
Non-proxy  Control  Distribute  VCC:  0.90 
Proxy  Control  Distribute  VCC: 

Multicast  Forward  VCC:  0.92 
Number  of  local  clients:  3 

LEC  #1  at  47.0005.80.FFE100.0000.F21A.3E9A.00204804ED46.00  (vl, non-proxy) 
OO-2O-48-04-ED-46  ->  47.0005.80.FFE100.0000.F21A.3E9A.00204804ED46.00 
Control  Direct  VCC:  0.89 

LEC  #2  at  47.0005. 80.FFE100.0000.F21A.3E9A.00204804EA93.00  (vl, non-proxy) 
02-20-48-04-EA-93  ->  47.0005.80.FFE100.0000.F21A.3E9A.00204804EA93.00 
Control  Direct  VCC:  0.94 

LEC  #3  AT  47 .0005 . 80.FFE 1 00.0000.F2 1  A.3E9  A. 002048 1 A3E9  A.  1 1  (vl, non-proxy) 
00-20-48-1 A-3E-9A  ->  47.0005.80.FFE100.0000.F21  A.3E9A.0020481A3E9A.1 1 
Name:  SHIP 

Control  Direct  VCC:  0.99 
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APPENDIX  D.  RAW  DATA  FROM  SOCKET  WRENCHER  TRIALS 


Zero  Propagation  Delay 


Window 

Single 

Split 

Ethernet 

ShipServ 

1 

841.59 

603.27 

827.062 

791.203 

2 

1293.33 

960.561 

1250.402 

1230.509 

4 

1828.89 

1779.113 

8 

2438.097 

1545.753 

2388.573 

2293.334 

Window 

Single 

Split 

Ethernet 

ShipServ 

1 

853.333 

640.00 

826.027 

788.48 

2 

1351.68 

648.907 

1280 

4 

1904.64 

1464.32 

1781.76 

1761.28 

8 

2054.702 

1751.04 

2074.81 

2050.979 

64K 


Window 


Ethernet  ShipServ 


866.16  686.96  849.92  814.08 


1042.432  936.96  1040.756  1035.729 


1077.62  1099.188  1082.647  1080.971 


8  1101.079  1072.593  1104.43  1099.403 


5msec  Propagation  Delay 

PTm 


Window 


|  Single 


86.732 


160.421 


300.167 


332.683 


128K 


Window 


64K 


Window 


311.312 


337.234 


Single 

Split 

84.48 

87.374 

164.103 

164.759 

292.571 

290.743 

319.391 

314.514 

Single 

Split 

88.99 

87.721 

172.373 

162.133 

294.4 

273.067 

307.2 

294.4 

10msec  Propagation  Delay 


1M 


Window  |  Single  (Split 


48.178  47.163 


93.388  91.982 


181.614  175.826 


8  189.692  184.336 


20msec  Propagation  Delay 


128K 


Window 


64K 


Window 


(Single 


47.741 


92.889  90.865 


169.354  163.446 


8  174.545  170.667 


Single  Split 


47.543  46.343 


91.927  88.436 


156.038  152.381 


8  162.133  158.476 


Window 


128K 


Window 


64K 


Window 


Single 

Split 

24.795 

24.53 

49.118 

IMEIjcy 

95.504 

94.008 

97.86 

96.112 

Single 

Split 

22.311 

24.381 

48.422 

47.176 

88.858 

87.559 

90.46 

89.246 

Single 

Split 

24.381 

24.154 

47.543 

47.1 

82.38 

81.067 

84.021 

82.051 

50msec  Propagation  Delay 


100msec  Propagation  Delay 


Window 


128K 


Window 


64K 


Window 


Single 

Split 

10.094 

10.056 

20.094 

19.983 

39.502 

39.133 

39.896 

39.606 

Single 

Split 

10.025 

9.985 

19.771 

19.648 

36.704 

36.411 

36.904 

36.704 

Single 

Split 

9.942 

9.904 

19.907 

19.414 

33.748 

33.528 

34.023 

33.968 

Window 


128K 


Window 


64K 


Window 


Single 

Split 

5.078 

5.068 

10.122 

10.092 

19.959 

19.844 

19.997 

19.988 

150msec  Propagation  Delay 


200msec  Propagation  Delay 


Window 


128K 


Window 


64K 


Window 


Single 

Split 

3.392 

3.388 

6.769 

6.754 

13.308 

12.948 

13.365 

13.132 

Single 

Split 

3.368 

3.364 

6.682 

6.637 

12.269 

12.31 

12.365 

12.303 

Single 

Split 

3.341 

3.337 

6.577 

6.566 

11.353 

11.116 

11.297 

11.423 

Window 


128K 


Window 


64K 


Window 


Single 

Split 

2.546 

2.544 

5.083 

5.072 

10.021 

9.798 

10.061 

9.962 

Single 

Split 

2.529 

2.527 

5.012 

4.983 

9.301 

9.12 

9.271 

9.276 

Single 

Captain  j 

2.529 

2.507 

5.012 

4.935 

9.301 

8.537 

9.271 

8.517 

1 


250msec  Propagation  Delay 


1MByte  File  8KByte  Buffer _ 

Delay  [msec]  Single _ Split _ 

0  2438.097  1545.753 

0.5  1599.192  1348.253 

1  1210.548  1021.411 

1.5  908.041  807.375 

2  _ 734.73  677.681 

2.5  637.292  581.588 

3  547.293  507.066 

3.5  484.001  450.032 

4  426.944  404.439 

4.5  390.248  368.626 

5  319.391  314.514 

10  189.692  184.336 

20  _ _ 97.86  96.112 

50 _ 39.896  *39.606 

100 _ 19.997  19.988 

150 _ 13.365  13.132 

200 _ 10.061  9.962 

250  4.701  4.264 


1MByte  File  4KByte  Buffer 


2KByte  Buffer 


1KByte  Buffer 


Single 

Split 

Single 

Split 

Single 

Split 

1828.89 

1298.65 

1293.33 

960.561 

841.59 

603.27 

1227.288 

1016.667 

780.953 

649.067 

456.65 

390.662 

953.138 

808.885 

562.758 

493.384 

313.172 

281.865 

779.429 

676.812 

437.33 

234.444 

220.762 

610.448 

578.505 

359.45 

331.556 

195.057 

181.597 

556.059 

507.258 

297.401 

285.237 

161.388 

153.381 

488.263 

450.413 

266.036 

249.835 

141.521 

133.871 

439.277 

404.401 

236.184 

222.974 

123.104 

118.388 

393.49 

368.359 

211.688 

200.893 

110.836 

106.187 

357.4 

336.62 

191.647 

182.506 

99.509 

96.064 

292.571 

290.743 

164.103 

164.759 

84.48 

87.374 

181.614 

175.826 

93.388 

91.982 

48.178 

47.163 

95.504 

94.008 

49.118 

48.39 

24.795 

24.53 

39.502 

39.133 

20.094 

19.983 

10.094 

10.056 

19.959 

19.844 

10.122 

10.092 

5.078 

5.068 

13.308 

12.948 

6.769 

6.754 

3.392 

3.388 

10.021 

9.798 

5.083 

5.072 

2.546 

2.544 

2.892 

2.887 

4.066 

4.062 

2.038 

2.036 

151 

20< 

25< 


128KByte  File  8KByte  Buffer 

Delay  [msec] 

Single 

Split 

0 

2054.702 

1751.04 

5 

319.391 

314.514 

10 

189.692 

170.667 

20 

97.86 

89.246 

50 

36.904 

36.704 

100 

18.468 

18.534 

150 

12.365 

12.303 

200 

9.271 

9.276 

250 

5.97 

6.053 

128  KByte  File  4KByte  Buffer 

Delay  [msec] 

Single 

Captain 

0 

1904.64 

1464.32 

5 

292.571 

290.743 

10 

181.614 

163.446 

20 

95.504 

87.559 

50 

36.704 

36.411 

100 

18.509 

18.202 

150 

12.269 

12.31 

200 

9.301 

9.12 

250 

4.934 

4.756 

128  KByte  File  2KByte  Buffer 

Delay  [msec] 

Single 

Split 

0 

1351.68 

648.907 

5 

164.103 

164.759 

10 

93.388 

90.865 

20 

49.118 

47.176 

50 

19.771 

19.648 

100 

9.99 

9.968 

150 

6.682 

6.637 

200 

5.012 

4.983 

250 

3.868 

4.005 

128  KByte  File  1KByte  Buffer 

Delay  [msec] 

Single 

Split 

0 

853.333 

640.00 

5 

84.48 

87.374 

10 

48.178 

46.816 

20 

24.795 

24.381 

50 

10.025 

9.985 

100 

5.039 

5.031 

150 

3.368 

3.364 

200 

2.529 

2.527 

250 

1.949 

2.023 

64KByte  File  8KByte  Buffer 

Delay  [msec] 

Single 

Split 

0 

1101.079 

1072.593 

5 

307.2 

294.4 

10 

162.133 

158.476 

20 

84.021 

82.051 

50 

34.023 

33.968 

100 

17.125 

17.097 

150 

11.297 

11.423 

200 

9.271 

8.517 

250 

6.889 

6.889 

64  KByte  File  4KByte  Buffer 

Delay  [msec] 

Single 

Split 

0 

1077.62 

1099.188 

5 

294.4 

273.067 

10 

156.038 

152.381 

20 

82.38 

81.067 

50 

33.748 

33.528 

100 

16.817 

16.861 

150 

11.353 

11.116 

200 

9.301 

8.537 

250 

6.68 

6.818 

64  KB 

yte  File  2KByte  Buffer 

Delay  [msec] 

Single 

Split 

0 

1042.432 

936.96 

5 

172.373 

162.133 

10 

91.927 

88.436 

20 

47.543 

47.1 

50 

19.907 

19.414 

100 

9.832 

9.686 

150 

6.577 

6.566 

200 

5.012 

4.935 

250 

3.79 

3.861 

64  KBi 

yte  File  1  KByte  Buffer 

Delay  [msec] 

Single 

Split 

0 

866.16 

686.96 

5 

88.99 

87.721 

10 

47.543 

46.343 

20 

24.381 

24.154 

50 

9.942 

9.904 

100 

5.002 
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